我一直在使用一些基本的 AOP 风格的解决方案来解决安全、日志记录、验证等横切问题。我的解决方案围绕着Castle Windsor和 DynamicProxy,因为我可以使用基于 Boo 的 DSL 应用所有内容并保持我的代码没有属性. 周末有人告诉我看一下PostSharp,因为它应该是一个“更好”的解决方案。我已经快速浏览了 PostSharp,但我被 Attribute 的使用吓到了。
有没有人尝试过这两种解决方案并愿意分享他们的经验?
我一直在使用一些基本的 AOP 风格的解决方案来解决安全、日志记录、验证等横切问题。我的解决方案围绕着Castle Windsor和 DynamicProxy,因为我可以使用基于 Boo 的 DSL 应用所有内容并保持我的代码没有属性. 周末有人告诉我看一下PostSharp,因为它应该是一个“更好”的解决方案。我已经快速浏览了 PostSharp,但我被 Attribute 的使用吓到了。
有没有人尝试过这两种解决方案并愿意分享他们的经验?
PostSharp的几个小问题......
我在使用 PostSharp 时遇到的一个问题是,在使用 asp.net 时,异常消息的行号被 PostSharp 注入程序集的 IL 指令的数量“输出”了,因为 PDB 也没有注入 :-)。
此外,如果没有运行时可用的 PostSharp 程序集,则会发生运行时错误。使用 Windsor,可以在以后关闭横切,而无需重新编译代码。
(希望这是有道理的)
我只看了一小段时间(还)温莎城堡,所以我不能对此发表评论,但我确实使用了 postsharp。
Postsharp 通过在编译时编织来工作。它会在您的构建中添加一个后编译步骤,用于修改您的代码。代码的编译就像您刚刚将横切关注点编程到您的代码中一样。这比运行时编织性能要好一些,并且由于使用属性 Postsharp 非常易于使用。我认为将属性用于 AOP 并不像将其用于 DI 那样有问题。但这只是我个人的口味。
但...
如果您已经将城堡用于依赖注入,我看不出您不应该将其用于 AOP 的充分理由。我认为虽然 AOP 在运行时比在编译时慢一点,但它也更强大。在我看来,AOP 和 DI 是相关的概念,所以我认为对两者使用一个框架是个好主意。所以我可能会在下一个我需要 AOP 的项目中再次查看城堡的东西。