Сборка широких многоадресных атрибутов. Они злые?

Question

Я работаю над проектом, в котором у нас есть несколько атрибутов в AssemblyInfo.cs, которые являются многоадресными для методов определенного класса.

[assembly: Repeatable(
AspectPriority = 2,
AttributeTargetAssemblies = "MyNamespace",
AttributeTargetTypes = "MyNamespace.MyClass", 
AttributeTargetMemberAttributes = MulticastAttributes.Public,
AttributeTargetMembers = "*Impl", Prefix = "Cls")]

Что мне не нравится в этом, так это то, что он добавляет кусочек логики в AssemblyInfo ( Info , обратите внимание!), Который для начала вообще не должен содержать никакой логики. Хуже всего то, что фактический MyClass.cs не имеет атрибута где-либо в файле, и совершенно неясно, могут ли они использоваться в методах этого класса. С моей точки зрения, это сильно ухудшает читабельность кода (не говоря уже о том, что чрезмерное использование PostSharp может сделать отладку кошмаром). Особенно, если у вас несколько атрибутов многоадресной рассылки.

Какая лучшая практика здесь? Кто-нибудь там использует атрибуты PostSharp, как это?

Answer 1

Позвольте мне сначала ответить Максу: действительно, аспекты не являются альтернативой хорошим шаблонам ООП. Они являются дополнением . Любой хороший дизайн АОП начинается с хорошего дизайна ООП. Но ООП-шаблоны иногда вынуждают вас писать много кода вручную. В этих случаях аспекты могут использоваться для автоматизации реализации шаблона ООП, не для их замены.

Когда вы пользуетесь AOP с умом, ваше решение может стать проще для понимания (бизнес-код не смешивается с кодом обслуживания), для тестирования (вы можете протестировать аспект независимо от бизнес-кода, т.е. вам не нужно тестировать что-либо бизнес-метод отслеживает правильно), измените (вам просто нужно изменить аспект, когда вы хотите изменить шаблон, вместо того, чтобы менять каждую реализацию шаблона). Теперь, если вы злоупотребляете AOP, если вы используете его в качестве инструмента хакерства, если вы не мыслите с точки зрения шаблонов ООП раньше, то вы получите больше затрат, чем пользы от AOP. Как любой острый инструмент, АОП следует использовать с умом.

Вернуться к исходному вопросу.

Кто сказал, что вы должны помещать аспекты в AssemblyInfo.cs? Вы можете создать новый файл с именем GlobalAspect.cs и поместить туда все аспекты уровня сборки. Вы правы, что AssemblyInfo.cs должен использоваться только для метаданных уровня сборки.

Но, как и вы, мне не нравятся аспекты на уровне сборки. Я думаю, что следует избегать. Основная проблема с аспектами на уровне сборки заключается в том, что они полагаются на соглашения об именах, и это зло. (Это зло называется хрупкость pointcut в академическом сообществе AOSD.) Действительно, когда вы переименовываете класс или пространство имен, вы меняете набор методов, к которым применяется аспект, и это может быстро стать кошмаром. Вот почему я никогда не использую для себя аспекты, основанные на соглашениях об именах.

А как насчет читаемости кода? Я думаю, что читаемый код в значительной степени является коротким кодом. Если у меня есть бизнес-метод CreateProduct, я, вероятно, хочу увидеть только код, создающий продукт. Большую часть времени меня не интересует код, который обрабатывает транзакции, исключения или трассировку. Достаточно, если я знаю, что некоторые аспекты справляются с этим для меня.

А откуда я знаю? С PostSharp у вас есть расширение Visual Studio. С AspectJ у вас есть плагин AspectJ для Eclipse (AJDT). В IDE они показывают, какие аспекты применяются к коду, который вы видите в данный момент. И если вы действительно хотите видеть детали (но вы редко этого хотите), вы можете использовать отладчик для перехода к аспектам или использовать Reflector для просмотра созданного кода.

Резюме:

1. Хороший дизайн АОП всегда начинается с хорошего дизайна ООП.
2. Избегайте использования соглашений об именах для применения аспектов.
3. Используйте расширение PostSharp для Visual Studio или AJDT для визуализации аспектов в вашем коде.

Answer 2

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

Ваши инстинкты верны. Помещение логики в метаданные любого рода - это ужасный, ужасный грех, за который вечно горит огонь ада неосуществимости.

Я имею в виду неуважение, хотя я уверен, что это будет истолковано иначе.

Лучшей практикой было бы не использовать инструменты «аспектно-ориентированного программирования», которые являются костылями, позволяющими избежать плохой практики проектирования и тестирования. Вместо этого посмотрите на свой дизайн и спросите себя «почему».

Почему я чувствовал необходимость использовать это инструмент? Какая у меня была проблема с дизайном? пытаясь решить?

Как только вы решите проблему, выберите Объясненные шаблоны проектирования (Shalloway & Trott) или Шаблоны проектирования Head First (Фриман, Робсон, Бейтс и Сьерра ).

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