汇编宽组播属性.他们是邪恶的吗？

Question

我正在开发一个项目,我们在AssemblyInfo.cs中有几个属性,这些属性被多播到特定类的方法.

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

我不喜欢这个,是它把一个逻辑放入AssemblyInfo(信息,请注意!),对于初学者来说根本不应该包含任何逻辑.最糟糕的部分是,实际的MyClass.cs在文件中没有任何属性,并且完全不清楚这个类的方法可能有它们.从我的角度来看,它极大地损害了代码的可读性(更不用说过度使用PostSharp会使调试成为一场噩梦).特别是当你有多个组播属性时.

这里的最佳做法是什么？有没有人使用像这样的PostSharp属性？

Answer 1

让我首先回答Max:事实上,方面不是优秀OOP模式的替代方案.它们是一种补充.任何良好的AOP设计都从良好的OOP设计开始.但OOP模式有时会迫使您手动编写大量管道代码.对于这些情况,方面可用于自动执行OOP模式,而不是替换它们.

当您智能地使用AOP时,您的解决方案可以变得更容易理解(业务代码不与维护代码混合),进行测试(您可以独立于业务代码测试方面,即您不必测试任何业务方法跟踪正确),更改(您只需要在更改模式时更改方面,而不是更改模式的每个实现).现在,如果您滥用AOP,如果您将其用作黑客工具,如果您之前没有考虑过OOP模式,那么您将获得的成本高于AOP的成本.作为任何尖锐的工具,应该智能地使用AOP.

回到原来的问题.

谁告诉你应该在AssemblyInfo.cs中放置方面？您可以创建一个名为GlobalAspects.cs的新文件,并将所有程序集级别的方面放在那里.你是对的,AssemblyInfo.cs应该只用于汇编级元数据.

但是和你一样,我不喜欢汇编级方面.我认为应该避免.组装级方面的主要问题是它们依赖于命名约定,这是邪恶的.(这种邪恶在学术AOSD社区中被称为切入点脆弱.)实际上,当您重命名一个类或命名空间时,您可以更改该方面适用的方法集,这很快就会成为一场噩梦.这就是我从不使用基于命名约定的方面的原因.

代码可读性怎么样？在很大程度上,我认为可读代码是短代码.如果我有一个名为CreateProduct的业务方法,我可能只想看到创建产品的代码.大多数时候,我对处理事务,异常或跟踪的代码不感兴趣.如果我知道某些方面可以解决这个问题就足够了.

我怎么知道？使用PostSharp,您可以使用Visual Studio扩展.使用AspectJ,您可以使用Eclipse的AspectJ插件(AJDT).它们在IDE内部向您显示哪些方面应用于您当前看到的代码.如果你真的想看到细节(但你很少真的想要),你可以使用调试器进入方面,或使用Reflector查看生成的代码.

摘要:

1. 良好的AOP设计总是从良好的OOP设计开始.
2. 避免依赖命名约定来应用方面.
3. 使用Visual Studio或AJDT的PostSharp扩展来可视化代码中的方面.