微軟是否正在爲C＃中的AOP解決方案？

Question

Microsoft是否正在爲C＃中的AOP提供解決方案？ （真正的AOP）選擇是什麼？

獎金的問題：是代碼契約的一種AOP的？

Answer 1

.net中的大多數依賴注入框架都具有使用AOP技術的能力，我個人更喜歡Ninject和Interceptor插件，因爲它易於使用，並且不需要任何對第三方屬性或任何事物的類污染。

話雖這麼說Spring.net，溫莎城堡和許多其他DI框架支持相同的原理略有不同的語法和方法，有些是XML驅動的一些是C＃驅動，你可以有編譯時的安全性。

一件事想的是，大多數DI框架通過類代理做到這一點，所以他們需要你的方法是虛擬的，然後在運行時，它的代理類的方法，你可以在這一點上攔截。還有其他一些方法，比如PostSharp所做的IL編織，它可以比代理更快，儘管我沒有任何測量來支持它。

沒有看到獎金問題位，對我來說，我會說它不是一個明確的答案，因爲它取決於你如何使用它，因爲通常你使用AOP作爲一種方式來分隔你的非功能性問題作爲日誌記錄，事務可能從源代碼中進行驗證，因此您可以從外部添加此邏輯，因此理想情況下，您的源代碼不知道AOP發生了什麼（儘管如果您使用的是某些第三方屬性，情況並非總是如此將您的源代碼連接到AOP框架）。

由於代碼合同可以寫在網上與現有的類或通過屬性鉤住或相信可以在運行時被完全注入，那麼像伐木關注你可以把他們都變成你的類，但使用時AOP的方法你不會。所以對於我來說Code Contracts只是一個強制執行的工具，你可以可以以AOP方式使用它，或者你可以將它嵌入到你的代碼中。

Answer 2

作爲替代方案，你也可以使用Spring AOP

鏈接：http://static.springsource.org/spring/docs/2.0.x/reference/aop.html

諾塔：我更喜歡統一

Answer 3

PostSharp是另一種選擇。容易入門，儘管它不再可以完全自由地使用。

我不知道，如果微軟仍然在積極推動該項目Unity。也許其他人可以對此有所瞭解。

Code Contracts不是（一種類型的）面向方面的編程。