Является ли AspectF (Fluent Aspect Framework) AOP-подобным проектом, который можно использовать без особого беспокойства? - PullRequest
9 голосов
/ 02 ноября 2009

Омар Аль Забир ищет «более простой способ кодирования в стиле AOP».

Он создал фреймворк под названием AspectF , который является «простым и простым способом добавления аспектов в ваш код».

Это не настоящий AOP , потому что он не выполняет никакого компиляции во время компиляции или выполнения, но выполняет ли он те же цели, что и AOP?

Вот пример использования AspectF:

    public void InsertCustomerTheEasyWay(string firstName, string lastName, int age,
        Dictionary<string, string> attributes)
    {
        AspectF.Define
            .Log(Logger.Writer, "Inserting customer the easy way")
            .HowLong(Logger.Writer, "Starting customer insert", "Inserted customer in {1} seconds")
            .Retry()
            .Do(() =>
                {
                    CustomerData data = new CustomerData();
                    data.Insert(firstName, lastName, age, attributes);
                });
    }

Вот несколько сообщений автора, которые дополнительно разъясняют цель AspectF:

По словам автора, я понимаю, что AspectF не предназначен для замены AOP , но является способом достижения "разделения забот и поддержания кода в чистоте и порядке".

Некоторые мысли / вопросы:

  • Есть мысли об использовании этого стиля кодирования по мере роста проекта?
  • Это масштабируемая архитектура?
  • проблемы производительности?
  • Как ремонтопригодность отличается от настоящего решения AOP?

Ответы [ 2 ]

5 голосов
/ 02 ноября 2009

Я не хочу разбивать проект, но ИМХО это злоупотребляет АОП. Аспекты не подходят для всего, и при таком использовании это только ухудшает читабельность.

Более того, я думаю, что это упускает один из основных моментов АОП, который заключается в возможности добавлять / удалять / переопределять аспекты, не затрагивая основной код.

Аспекты должны быть определены вне затронутого кода, чтобы сделать их действительно сквозными проблемами. В случае AspectF аспекты встроены в затронутый код, что нарушает SoC / SRP .

С точки зрения производительности, штраф не взимается (или незначителен), потому что нет манипуляций IL во время выполнения, как описано в статье codeproject. Однако у меня никогда не было проблем с Castle DynamicProxy.

3 голосов
/ 09 сентября 2011

В недавнем проекте мне порекомендовали попробовать AspectF. Я принял близко к сердцу идею изложить все проблемы заранее и иметь код, который делает реальную работу, блаженно не подозревая обо всех сдержках и противовесах, которые произошли за ее пределами.

На самом деле я пошел немного дальше и добавил «проблему безопасности», которая требовала учетные данные, которые были получены в рамках запроса WCF. Он ушел в базу данных и сделал то, что должен был. Я выполнил очевидные проверки и проверку безопасности перед запуском фактического кода, который вернул бы необходимые данные.

Я нашел этот подход довольно освежающим изменением, и мне, конечно, понравилось, что у меня был источник AspectF для прохождения, когда я отлаживал и тестировал сервисные вызовы.

В офисе некоторые утверждали, что эти проблемы должны быть реализованы в качестве украшения для класса / метода. Но на самом деле не имеет значения, где вы его украшаете, в какой-то момент вы должны сказать, что хотите выполнить определенные действия / проверки. Мне нравится тот факт, что все это размещено на месте, а не как другой файл кода, не как какой-то файл конфигурации, и на этот раз, не добавляя еще одно украшение в класс / метод.

Я не говорю, что это действительно АОП - и я, конечно, думаю, что есть решения и ситуации, когда это действительно не лучший способ реализации ваших целей, но, учитывая, что это всего лишь пара К исходных файлов, которые делают для очень легкой реализации.

AspectF - это очень умный способ объединения делегатов. Я не думаю, что каждый разработчик будет смотреть на код и говорить, как это замечательно, ведь в нашем офисе это смутило некоторых из нас! Но как только вы поймете, что происходит, это недорогой способ добиться многого из того, что можно сделать и другими подходами.

...