Влияние на AOP с атрибутами через МОК; запах кода или изящный?
Я использую StructureMap в данный момент, обычно с основанным на конвенции (Scan()) автоматическая конфигурация, и я надеюсь добавлять основанное на декораторе кэширование в конвейер.
Если я настраиваю его вручную, который прекрасен, но Scan() настолько удобно, когда Вы получаете много зависимостей... Я играю с замечанием предложений кэша в интерфейсе (интерфейсах), например:
public interface IFoo {
[CacheDuration(20)] // cache for 20 minutes
string[] DoSomethingReusable();
SomeType DoSomethingNonReusable(int key); // not cached
}
причем идея - это путем добавления пользовательской "конвенции" к StructureMapсканирование (довольно легкое), это может определить это, один или несколько методов украшены для кэширования и автоматически вводят сгенерированного декоратора кэширования в конвейер того типа (генерирующий ключ кэша от интерфейса/имени метода и значений параметров).
Зато это делает добавление, кэширующееся очень безболезненный - просто украшают интерфейс немного; но, запах кода? И/или я копирую что-то, что уже решено?
5 ответов
Атрибуты допустимы, если вы знаете о двух основных факторах:
по своей сути децентрализованная структура, вместо того, чтобы хранить ваши метаданные в одном месте для каждого компонента, которого он касается.
жесткая структура констант компилятора. Если вы вдруг решите, что продолжительность вашего кеша должна быть 10, а не 20, вам придется перекомпилировать весь свой код. Вы можете направлять атрибуты в такие вещи, как config, но это работает с атрибутами, и на этом этапе вы действительно должны пересмотреть, было ли их использование в первую очередь лучшей идеей.
Пока вы знаете об этих проблемах и согласны с ними, продолжайте.
Насколько я понимаю вопрос, вы в основном рассматриваете возможность добавления атрибутов, чтобы упростить регистрацию контейнера. Вы все еще реализуете кеши, используя шаблон проектирования Decorator, который, IMO, является правильным способом реализации кеширования.
Мы делаем то же самое в Safewhere, но вместо этого используем регистрацию на основе соглашения . Мы также используем Castle Windsor, поэтому я не знаю, возможно ли это с помощью StructureMap, но мы просто сканируем соответствующие сборки после чего-либо с именем Caching * Repository и регистрируем их как декораторы для реальных репозиториев. У нас также есть основанный на соглашении модульный тест, который проверяет наличие всех необходимых репозиториев кэширования.
Является ли добавление настраиваемого атрибута запахом кода или нет, зависит от требуемой степени повторного использования вашего кода.Мое практическое правило состоит в том, что я хочу быть способным связать все с DI для бедняков . Вместо этого я все еще использую контейнер DI, но это правило дает мне возможность проверить работоспособность.
В общем, мне не нравится связывать свой код с конкретным контейнером, но я не могу понять, делаете ли вы это здесь. Это зависит от того, нужно ли вам ссылаться на StructureMap для определения настраиваемого атрибута. Если вам нужно сослаться на карту структуры, я бы посчитал это запахом.
Я не могу сказать, что полностью все понимаю, но с моими 2 центами это, пожалуй, нормально; но мне просто интересно, легко или нет его поменять без перекомпиляции. И, возможно, вы захотите изменить продолжительность этого кеша с помощью записи конфигурации, а не компиляции. Я бы, вероятно, сохранил эти данные где-нибудь, где мне было бы проще настроить. (Возможно, я неправильно понял ...)
Единственный недостаток, который я вижу здесь, это то, что нет центральной точки, где объекты кэшируются. Обычно есть один конкретный слой, где кэширование выполняется. С вашей техникой это не так.
Я также думаю, что ответственность за решение, должно ли что-то быть кэшировано или нет, лежит на вашем коде, а не на классе/интерфейсе.
Но чтобы ответить на ваш вопрос, это запах кода? Я бы сказал нет, но для новых разработчиков это может быть запутанным, когда система используется во многих местах.
Я склонен согласиться с тем, что было сказано о том, что кеширование должно определяться вашим кодом, но другой сценарий, который, как я вижу, вы можете принять во внимание это «Что нужно кэшировать, весь объект?»
Возможно, вы захотите поиграть с идеей наличия свойств, чтобы установить, какие элементы вы не хотите кэшировать объекта.
Может быть, атрибут
[Cache(Duration=20, Location(...))]
]?