程序集寬度多播屬性。他們是邪惡的嗎？

Question

我正在一個項目中，我們在AssemblyInfo.cs中有幾個屬性，這些屬性被組播到特定類的方法中。

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

我不喜歡這個什麼，是它把一塊邏輯的成集信息（信息，請注意！），這對於初學者不應包含任何邏輯可言。最糟糕的部分是，實際的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顯示了哪些方面適用於您目前看到的代碼。如果你真的想看細節（但你很少真正想要），你可以使用調試器進入方面，或使用反射器來查看生成的代碼。

摘要：

1. 好AOP設計始終具有良好的面向對象設計開始。
2. 避免依靠命名約定來應用方面。
3. 使用Visual Studio或AJDT的PostSharp擴展來可視化代碼中的方面。

Answer 2

我敢肯定，這將是一個不受歡迎的答案，但也許我可以讓我的同輩壓力徽章......

你的直覺是正確的。將邏輯放在任何類型的元數據中都是一種可怕的，可怕的罪惡，人們在不可維護的地獄火中永遠燃燒着它。

我的意思是沒有不尊重，雖然我確信它會被解釋，否則。

最好的做法是不使用「aspect-oreinted programming」工具，這些工具是支撐不良設計和測試實踐的柺杖。相反，看看你的設計，問自己「爲什麼。」

爲什麼我覺得需要使用這個 工具？我試圖解決什麼設計問題是我 ？

一旦你有問題牢牢把握，去接設計模式的解釋（Shalloway &特洛特）或Head First設計模式（弗里曼，羅布森，貝茨，&塞拉利昂）。最後，面向模式的解決方案將更易於理解，更易於測試並更易於更改。唯一的額外費用將是掌握設計模式的一次性費用，而不是反覆嘗試弄清楚所有這些方面在哪裏，它們如何組合在一起，以及每次進行更改時如何相互影響。