Блок широкие многоадресные атрибуты. Действительно ли они являются злыми?
Я работаю над проектом, где у нас есть несколько атрибутов в AssemblyInfo.cs, которые многоадресно передаются к методам конкретного класса.
[assembly: Repeatable(
AspectPriority = 2,
AttributeTargetAssemblies = "MyNamespace",
AttributeTargetTypes = "MyNamespace.MyClass",
AttributeTargetMemberAttributes = MulticastAttributes.Public,
AttributeTargetMembers = "*Impl", Prefix = "Cls")]
То, что мне не нравится приблизительно это, то, что это помещает часть логики в AssemblyInfo (Информация, обратите внимание!), который для начинающих не должен содержать логику вообще. Худшая часть его, то, что фактический MyClass.cs не имеет атрибута нигде в файле, и абсолютно неясно, что методы этого класса могли бы иметь их. С моей точки зрения это значительно повреждает удобочитаемость кода (не говоря уже о том, что злоупотребление PostSharp может сделать отладку кошмара).Especially, когда у Вас есть несколько многоадресных атрибутов.
Какова лучшая практика здесь? Кто-либо, там использует атрибуты PostSharp как это?
2 ответа
Позвольте мне сначала ответить Максу: действительно, аспекты не являются альтернативой хорошим шаблонам ООП. Они являются дополнением . Любой хороший дизайн АОП начинается с хорошего дизайна ООП. Но шаблоны ООП иногда вынуждают вас писать много сантехнического кода вручную. В этих случаях аспекты могут использоваться для автоматизации реализации шаблона ООП, не для их замены.
Если вы используете АОП с умом, ваше решение может стать более простым для понимания (бизнес-код не смешивается с кодом обслуживания), для тестирования (вы можете тестировать аспект независимо от бизнес-кода, т.е. вам не нужно тестировать что-либо бизнес-метод трассируется правильно), изменение (вам просто нужно изменить аспект, когда вы хотите изменить шаблон, вместо того, чтобы изменять каждую реализацию шаблона). Теперь, если вы злоупотребляете АОП, если вы используете его в качестве хакерского инструмента, если вы раньше не мыслили в терминах шаблонов ООП, тогда вы получите больше затрат, чем преимуществ от АОП. Как любой острый инструмент, АОП следует использовать с умом.
Вернуться к исходному вопросу.
Кто сказал, что вам следует помещать аспекты в AssemblyInfo.cs? Вы можете создать новый файл с именем GlobalAspect.cs и поместить туда все аспекты уровня сборки. Вы правы, что AssemblyInfo.cs должен быть предназначен только для метаданных уровня сборки.
Но, как и вы, мне не нравятся аспекты на уровне сборки.Думаю, этого следует избегать. Основная проблема с аспектами уровня сборки заключается в том, что они полагаются на соглашения об именах, а это зло. (В академическом сообществе AOSD это зло называется pointcut .) Действительно, когда вы переименовываете класс или пространство имен, вы меняете набор методов, к которым применяется этот аспект, и это может быстро превратиться в кошмар. Вот почему я никогда не использую для себя аспекты, основанные на соглашениях об именах.
А как насчет читабельности кода? В значительной степени я считаю, что читаемый код - это короткий код. Если у меня есть бизнес-метод CreateProduct, я, вероятно, хочу видеть только код, создающий продукт. В большинстве случаев меня не интересует код, обрабатывающий транзакции, исключения или трассировку. Достаточно, если я знаю, что некоторые аспекты справляются с этим за меня.
А откуда я знаю? С PostSharp у вас есть расширение Visual Studio. С AspectJ у вас есть подключаемый модуль AspectJ для Eclipse (AJDT). Они показывают вам внутри IDE, какие аспекты применяются к текущему коду. И если вы действительно хотите видеть детали (но редко действительно этого хотите), вы можете использовать отладчик для перехода к аспектам или использовать Reflector для просмотра созданного кода.
Резюме:
- Хороший дизайн АОП всегда начинается с хорошего дизайна ООП.
- Не полагайтесь на соглашения об именах для применения аспектов.
- Используйте расширение PostSharp для Visual Studio или AJDT, чтобы визуализировать аспекты вашего кода.
Я уверен, что это будет непопулярный ответ, но, может быть, я смогу получить значок моего давления со стороны сверстников ...
Ваши инстинкты верны. Включение логики в метаданные любого вида - это ужасный, ужасный грех, из-за которого человек вечно горит в адском огне невозможности поддерживать.
Я не подразумеваю под этим неуважение, хотя уверен, что это будет истолковано иначе.
Лучшей практикой было бы не использовать инструменты «аспектно-ориентированного программирования», которые представляют собой костыли, позволяющие избежать неудач из-за плохой практики проектирования и тестирования. Вместо этого посмотрите на свой дизайн и спросите себя «почему».
Почему я почувствовал необходимость использовать этот инструмент ? Какую проектную проблему я пытался решить?
Как только вы получите твердое представление о проблеме, возьмите Design Patterns Explained (Shalloway & Trott) или Head First Шаблоны проектирования (Фриман, Робсон, Бейтс и Сьерра).
В конце концов, решение, ориентированное на шаблоны, будет проще для понимания, тестирования и изменения. Единственными дополнительными расходами будут единовременные выплаты за освоение шаблонов проектирования вместо регулярных затрат на попытки выяснить, где находятся все эти аспекты, как они сочетаются друг с другом и как они влияют друг на друга каждый раз, когда вы вносите изменения.