C# 程序集范围的多播属性。他们是邪恶的吗？

我正在从事一个项目，其中AssemblyInfo.cs中有几个属性，它们被多播到特定类的方法

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

我不喜欢的是，它将一段逻辑放入AssemblyInfo（Info，请注意！），对于初学者来说，它不应该包含任何逻辑。最糟糕的是，实际的MyClass.cs在文件中的任何地方都没有该属性，而且完全不清楚该类的方法是否具有该属性。从我的角度来看，这极大地损害了代码的可读性（更不用说过度使用PostSharp会使调试成为一场噩梦）

---

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

我相信这将是一个不受欢迎的答案，但也许我可以得到我的同侪压力徽章

你的直觉是正确的。在任何类型的元数据中加入逻辑都是一种可怕的罪恶，人们为此在无法维护的地狱之火中永远燃烧

我的意思是没有不尊重，虽然我相信这将被解释为其他

最好的做法是不要使用“面向方面的编程”工具，这些工具是导致糟糕的设计和测试实践失败的拐杖。相反，看看你的设计，问问自己“为什么”

为什么我觉得有必要用这个 工具？我遇到了什么设计问题 试图解决

一旦你对这个问题有了一个明确的理解，就去选择解释过的设计模式（Shalloway&Trott）或头先设计模式（Freeman、Robson、Bates和Sierra）

---

最终，面向模式的解决方案将更易于理解、测试和更改。唯一的额外成本将是掌握设计模式的一次性费用，而不是试图找出所有这些方面的位置、它们如何组合以及每次进行更改时它们如何相互影响的重复费用。

让我首先回答Max：事实上，方面并不是好的OOP模式的替代品。它们是一种补充。任何好的AOP设计都是从一个好的OOP设计开始的。但OOP模式有时会迫使您手动编写大量管道代码。对于这些情况，方面可以用来自动化OOP模式的实现，而不是取代它们

当您智能地使用AOP时，您的解决方案可以变得更容易理解（业务代码不与维护代码混合）、测试（您可以独立于业务代码测试方面，即不必测试任何业务方法是否正确跟踪）、更改（当您想要更改模式时，只需更改方面，而不是更改模式的每个实现）.现在，如果你滥用AOP，如果你将其用作黑客工具，如果你以前不考虑OOP模式，那么你将从AOP中获得更多的成本而不是收益。作为任何锐利的工具，AOP应该明智地使用

回到原来的问题

谁告诉你应该将方面放在AssemblyInfo.cs中？你可以创建一个名为GlobalSpects.cs的新文件，并将所有程序集级方面放在那里。你说得对，AssemblyInfo.cs应该只用于程序集级元数据

但和你一样，我不喜欢汇编级方面。我认为应该避免。汇编级方面的主要问题是它们依赖于命名约定，这是邪恶的。（这种邪恶在学术AOSD社区中被称为切入点脆弱性。）事实上，当您重命名一个类或名称空间时，您会更改方面应用到的方法集，这很快就会成为一场噩梦。这就是为什么我从不为自己使用基于命名约定的方面

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

我怎么知道呢？使用PostSharp，您有Visual Studio扩展。使用AspectJ，您有用于Eclipse的AspectJ插件（AJDT）。它们在IDE中向您显示哪些方面应用于您当前看到的代码。如果您真的想看到详细信息（但您很少真正想要），您可以使用调试器逐步进入方面，或使用Reflector查看生成的代码

总结：

好的AOP设计总是从好的OOP设计开始

避免依赖命名约定来应用方面

使用Visual Studio或AJDT的PostSharp扩展来可视化代码中的方面

---

我不知道PostSharp扩展。可能它安装不正确。这是PostSharp 2.0.Max的一个新功能-我正在开发一个解决方案，该解决方案有134个项目，现在需要对这些项目进行测试以提高性能。重新思考和重构50多万行代码根本不是一个选项。这是一个真实的世界对于企业应用程序，无论出于何种原因，这些情况都存在。PostSharp提供了一个非常强大的解决方案。我没有选择返回到解释过的设计模式，并在长达15年的时间里追踪数百份关于代码的合同。我也在同一条船上。遗留企业应用程序。大约20个项目b、 net一些c#。我需要记录性能分析。无法想象手动向数千个类甚至更多方法添加代码。