Блог

Предположим, что критическая часть бизнес-правил приложения зависит от заданного поведения, но явное кодирование этого поведения приведет к загромождению вашего кода, будете ли вы полагаться на инкапсуляцию его в аспекте с помощью PostSharp (или любой другой структуры аспектов, если на то пошло)? Является ли это «безопасным» и «разумным» вариантом, или всегда лучше явно кодировать поведение, независимо от того, как оно будет загромождать код? Как насчет ремонтопригодности такого решения?

Не рекомендуется помещать бизнес-правила или бизнес-логику в аспекты. Это противоречит цели AOP. Бизнес-правила / логика не являются сквозными проблемами. Если вы рассматриваете часть своей бизнес-логики как беспорядок, вам следует использовать общие методы ООП, чтобы абстрагировать ее или извлечь ее в собственные методы.

Вы, конечно, можете перенести это в аспект, но какова будет цель? Чтобы уменьшить беспорядок? Для меня это неприемлемо. Используйте аспекты для удаления беспорядка, не связанного с бизнес-логикой, чтобы ваша бизнес-логика была понятной. Если ваша бизнес-логика загромождена, вам необходимо провести рефакторинг.

PostSharp против других фреймворков AOP: Если вы в конечном итоге помещаете «критический код» в аспект, то PostSharp будет лучшим фреймворком для достижения наилучшей производительности. Фреймворки времени выполнения, такие как IoC, которые выполняют динамический перехват, не будут работать так же хорошо, как статически скомпилированный код. Кроме того, PostSharp имеет так много оптимизаций, которые он выполняет на основе написанного вами кода, что никакая другая платформа не может сравниться.