在業務邏輯中使用反射是否是一種好的做法？

Question

我需要在一個由兩個主要部分組成的應用程序工作：

• 業務邏輯部分的具體業務類（如圖書，圖書館，作者，...）
• 通用部分，可在數據網格中顯示Books，Libraries，...，將它們映射到數據庫...）。

泛型部分使用反射來從業務類中獲取數據，而無需在業務類中編寫特定的數據網格或數據庫邏輯。這工作得很好，並允許我們無需調整數據網格和數據庫邏輯增加新的業務類（例如LibraryMember）。

但是，多年來，代碼被添加到業務類中，這些業務類還利用反射來完成業務類中的事情。例如。如果一本書的作者被改變，觀察家們打電話告訴作者本身，它應該本書添加到其收藏的由他（Author.Books）寫的書。在這些觀察員，不僅實例都過去了，而且還直接從反思中得到的信息（這樣，來電者知道，這本書領域的「作者」是改變字段信息添加到觀察者調用）。

我可以清楚地看到在這些通用模塊（如數據網格或數據庫接口）中使用反射的優點，但在我看來，在業務類中使用反射是一個壞主意。畢竟，應用程序不應該儘量不依賴反思工作？還是在21世紀反思「正常工作方式」？

是因爲你的業務邏輯使用反射好的做法呢？

編輯：一些澄清柯克的一句話：

• 試想一下，作者實現對圖書的觀察​​員。
• 書呼籲所有的觀察者只要書的某些領域改變（如名稱，年份#Pages，作者，...）。更改字段的'FieldInfo'在觀察者中傳遞。
• 的作者，然後觀察者使用該字段信息，以決定是否有興趣在這個變化。在這種情況下，如果FieldInfo用於Book的字段Author，則Author-Observer將更新其自己的Books矢量。

Answer 1

我避免使用反射。是的，它使您的程序更加靈活。但是這種靈活性的代價很高：沒有編譯時檢查字段名稱或類型，或者通過反射收集的任何信息。

像很多事情一樣，這取決於你在做什麼。如果你的邏輯性質是你永遠不會比較發現的字段名稱（或其他）到一個常量值，那麼使用反射可能是一件好事。但是，如果您使用反射來查找字段名稱，然後循環搜索名爲「作者」和「標題」的字段，則可以使用兩個命名字段創建一個更復雜的對象模擬。如果您在字段實際稱爲「AuthorName」時搜索「作者」，或者您打算搜索「作者」並意外鍵入「Auhtor」？現在，您的錯誤將在運行時才顯示出來，而不是在編譯時標記出來。

使用硬編碼的字段名稱，您的IDE可以告訴您每個地方使用某個字段。有反思......不太容易說出來。也許你可以對名稱進行文本搜索，但是如果字段名稱作爲變量傳遞，它可能會變得非常困難。

我正在研究一個原始作者喜歡反射和類似技術的系統。有各種各樣的地方他們需要創建一個類的實例，而不是僅僅說「新」和類，他們創建一個令牌，他們在表中查找以獲取類名稱。這會得到什麼？是的，我們可以更改表格以將該標記映射到不同的名稱。這使我們獲益...什麼？你最後一次說什麼時候，「哦，我的程序創建客戶實例的每個地方，我想要更改爲創建NewKindOfCustomer的實例。」如果你對班級有所改變，你可以改變班級，不要創建一個新班級，而是留着舊班級留戀。

採取類似的問題，我隨時進行構建數據輸入屏幕的常規做法通過詢問數據庫字段名稱，類型和大小的列表，然後從那裏鋪設出來。這給了我使用同樣的程序對所有簡單的數據輸入屏幕的優勢 - 只是通過在表名作爲參數 - 如果一個字段添加或刪除，則需要零代碼的變化。但是，只要我不在乎這些領域是什麼，這隻會起作用。一旦我開始有驗證或副作用具體到這個畫面，該系統是更多的麻煩比它的價值，和我最好回落到更明確的編碼。

Answer 2

我傾向於不使用反射，我可以幫助它。通過使用接口和編碼對這些我可以做很多事情，有些人會使用反射。

但我是一個很大的粉絲，如果它的工作，它的作品。

另外通過使用反射，你可能有一些可以相當容易適應的東西。

即最大的唯一反對意見是相當宗教......如果你的表現很好，代碼是可以維護和清晰的....誰在乎？

編輯：根據你的編輯我確實會使用接口來實現你想要的。除非我誤解你。

Answer 3

我認爲在可能的情況下儘量遠離反射是一個好主意，但是當它爲您的問題提供更好或更靈活的解決方案時，不要害怕訴諸它。對於應用程序或Web Form請求的整體方案而言，除了緊密循環操作之外的任何其他性能都可能很小。

只是爲了分享反思的好文章 -

http://www.simple-talk.com/dotnet/.net-framework/a-defense-of-reflection-in-.net/

Answer 4

我傾向於使用接口在我的業務層和離開反射到我的表現層。這不是絕對的，而是一個指導方針。

Answer 5

反射的主要危險在於靈活性可能會升級爲無序的，不可維護的代碼，特別是如果更多的初級開發人員用於進行更改，誰可能不完全理解反射代碼或者如此癡迷以至於他們使用它解決所有問題，即使是簡單的工具就足夠了。

我的觀察是過度泛化會導致過度複雜化。當實際邊界案例變得不能被廣義設計所接受時，情況會變得更糟，這就要求黑客如期地適應新的特徵，將靈活性轉化爲複雜性。

Answer 6

根據您的編輯，它聽起來像您使用反射純粹作爲確定字段的機制。這與動態行爲相反，例如查找這些字段，應儘可能避免使用這些字段（因爲此類查找通常使用破壞靜態類型安全性的字符串）。使用FieldInfo爲字段提供標識符是相當無害的，但它確實以一種不完全理想的方式公開了一些內部信息（info類）。