Давайте попробуем принять архитектурное решение по этому вопросу. Скажи, что ты архитектор (каждый хочет быть архитектором;)
Вы должны предоставить архитектуру своей команде:
выбранный набор библиотек, архитектурных шаблонов и шаблонов проектирования. В рамках вашего проекта вы говорите: «Мы реализуем кэширование, используя следующий шаблон проектирования:»
string key = string.Format("[{0}].MyMethod({1},{2})", this, param1, param2 );
T value;
if ( !cache.TryGetValue( key, out value ) )
{
using ( cache.Lock(key) )
{
if (!cache.TryGetValue( key, out value ) )
{
// Do the real job here and store the value into variable 'value'.
cache.Add( key, value );
}
}
}
Это правильный способ трассировки. Разработчики собираются внедрять этот шаблон тысячи раз, поэтому вы пишете хороший документ Word, рассказывающий, как вы хотите, чтобы этот шаблон был реализован. Да, документ Word. У вас есть лучшее решение? Боюсь, что нет. Классические генераторы кода не помогут. Функциональное программирование (делегаты) Это работает довольно хорошо для некоторых аспектов, но не здесь: вам нужно передать параметры метода в шаблон. Так что осталось? Опишите шаблон на естественном языке, и разработчики могут его реализовать.
Что будет?
Во-первых, какой-нибудь младший разработчик посмотрит код и скажет: «Хм. Два поиска в кэше. Какая-то бесполезная. Одного достаточно». (это не шутка - спросите команду DNN об этой проблеме). И ваши шаблоны перестают быть потокобезопасными.
Как архитектор, как вы обеспечиваете правильное применение шаблона? Модульное тестирование? Справедливо, но вы вряд ли обнаружите проблемы с многопоточностью. Обзор кода? Возможно, это решение.
Теперь, что вы решили изменить шаблон? Например, вы обнаружили ошибку в компоненте кэша и решили использовать свою собственную? Собираетесь ли вы редактировать тысячи методов? Это не просто рефакторинг: что если новый компонент имеет другую семантику?
Что если вы решите, что метод больше не будет кэшироваться? Насколько сложно будет удалить кеширующий код?
Решение AOP (независимо от структуры) имеет следующие преимущества по сравнению с простым кодом:
- Это уменьшает количество строк кода .
- Это уменьшает связь между компонентами , поэтому вам не нужно много менять, когда вы решите изменить компонент протоколирования (просто обновите аспект), поэтому улучшает емкость Ваш исходный код, чтобы справиться с новыми требованиями с течением времени .
- Поскольку кода меньше, вероятность ошибок для данного набора функций ниже, поэтому AOP улучшает качество вашего кода .
Итак, если вы сложите все вместе:
Аспекты снижают как затраты на разработку, так и на обслуживание программного обеспечения.
У меня 90 минут разговора на эту тему, и вы можете посмотреть его на http://vimeo.com/2116491.
Опять же, архитектурные преимущества AOP не зависят от выбранной вами платформы. Различия между фреймворками (также обсуждаемыми в этом видео) в основном влияют на степень, в которой вы можете применить AOP к своему коду, что не было целью этого вопроса.