重構解決方案使用實體框架4.3（代碼優先）

Question

我想問一些建議： 我們有一個解決方案，使用經典的ADO.NET數據訪問（它像4歲以上）。 的數據訪問結構，在.NET 2.0. 我們的數據類的時間建成背面都具有CRUD操作的默認實現所，比如說，從FooDataBaseObject繼承簡單類（名稱實際上並不事）。我們的屬性被標記爲自定義屬性（保存必要的數據，如表格中各列的名稱等）。和數據類一樣（自定義屬性用於指定表名等）。

---

實體之間的關係在特殊的.xsd和.xml文件中指定。這些表本身很少有外鍵和其他典型的約束（我們實際上有這張表被繼承，客戶禁止我們修改它們，因爲它們仍然使用導入和導出引擎）。但我相信我將能夠說服人們重構數據庫。

---

問題在於現有的服務。有沒有辦法引入EF仍有可能使用舊的ado.net服務？ 我目前考慮使用EF代碼第一次方法的想法，因爲我並不需要生成我的實體不繼承或某些特定類等，而不是我可以（我希望）來構建一個DbContext他們並映射到現有的數據庫。 另外，可能有一種方法可以爲我們的舊數據類創建鏡像類。說Customer - >CustomerEntity。 CustomerEntity將鏡像Customer的所有必要屬性，然後在DbContext和DbSet中使用，以便我們將在舊服務中使用CustomerEntity，而在Customer中使用舊服務。

我想聽聽這種方法的潛在瓶頸，以及這種可能性（這實際上是真的嗎？）還是其他一些建議等等。 謝謝！

Answer 1

你將有很多使用EF如果表沒有外鍵關係問題。 EF通常會依靠這些關係來創建代碼中的關係。

當然，你可以把它們作爲單獨的表 - >單個對象和處理手動所有的按鍵。

您不可能將這些類無需修改就映射到舊代碼，因爲您的舊代碼似乎依賴於它自己的幫助器方法以及提交或回滾數據的方式。不知道你現有的對象模型，很難說。

我會做的就是創建一個EF模型，然後開始使用它一塊一塊的，你升級你的應用程序。只要你現有的代碼處理孤立的事情，並且整個代碼中沒有太多依賴。