应用面向切面编程技术

Question

我一直在使用基本的AOP风格解决方案来处理诸如安全性、日志、验证等交叉关注点。我的解决方案围绕着Castle Windsor 和 DynamicProxy展开，因为我可以使用基于Boo的DSL应用所有内容，并保持代码不带属性（Attributes）。上个周末有人告诉我要看看PostSharp，因为它被认为是一种“更好”的解决方案。我快速看了一下PostSharp，但由于使用属性（Attributes）而被打消了兴趣。

是否有人尝试过这两种解决方案，并愿意分享他们的经验？

- Chris Canal

Answer 1

使用PostSharp时出现了几个小问题...

一个问题是在使用asp.net时，异常信息的行号会偏移PostSharp注入到程序集中的IL指令数量，因为PDB文件没有被同时注入进去。 :-)

此外，在运行时如果没有可用的PostSharp程序集，则会发生运行时错误。使用Windsor可以在稍后关闭横切面，而无需重新编译代码。

(希望这样说有意义)

- Stacy A

---

这是一个我无意中发现的相当久远的答案，但我想指出的是，PostSharp现在确实会转换PDB文件，所以不再存在调试问题了（参见：http://stackoverflow.com/questions/2006508/postsharp-pdb-debugging-and-referenced-assemblies）。 - Matthew Groves

Answer 2

我只是简短地浏览了castle-windsor，所以无法对其进行评论，但我使用了postsharp。

Postsharp通过编译时的织入来工作。它会在你的构建过程中添加一个后编译步骤，修改你的代码。代码被编译，就好像你刚刚将横跨多个方面的关注点编写进了代码中一样。这比运行时织入更具性能，而且由于使用了属性，Postsharp非常容易使用。我认为使用属性进行AOP并不像用于DI那样存在问题，但这只是我的个人喜好。

但是...

如果您已经使用castle进行依赖注入，我看不出为什么您不应该将其用于AOP方面。我认为尽管运行时的AOP比编译时的略慢，但它也更加强大。AOP和DI在我看来是相关的概念，因此我认为使用一个框架来处理两者是个好主意。所以下一个需要AOP的项目中我可能会再次查看castle。

- Mendelt Siebenga