是否將實體框架加入我的應用程序中適合我的情況？

Question

因此，我有一個使用SQL Server Express數據庫的應用程序。我有大約80個表都帶有主鍵但沒有外鍵。 （我們之所以沒有外鍵是因爲我們如何做我們的SQL客戶端到服務器複製，它不是真正的複製，但它是一個同步系統，當我們接管應用程序時已經到位了，我們不能保證記錄是什麼當客戶端與服務器同步時，首先將其傳送到數據庫，因此記錄可能會使用指向非遠程記錄的外鍵將其記錄到數據庫）。

我們使用每類型的約定。對於我們的每個業務對象，db中都有一個表。我們目前使用每個數據庫事務的存儲過程。這意味着每個新班級至少有4個新的存儲過程（crud）。我們從業務對象中抽象出了數據訪問層。每個業務對象都有一個對應的businessObjectDAO。

我的問題是，我的移動實體框架是否可行？沒有外鍵關係，我將不得不手動設置表之間的每個關聯。這是值得的時間嗎？

我現在最大的困惑就是想知道如何將我的DAO映射到EF部分類。

我應該創建一個大的.edmx還是多個？

我知道很多問題。這是我的第一個大型架構類型決策，如果我認爲這是有益和可行的，我已經給出了改進的意見。

也許我應該試試Linq-to-SQL？ NHibernate出局是因爲我們不允許在生產環境中使用開源產品（我知道這很愚蠢）。

感謝 科迪

Answer 1

我個人的建議是，如果事情是工作，離開它。我是LINQ-SQL和Entity Framework的忠實粉絲，並且已經設法使我的工作場所能夠使用Linq-Sql。我意識到，如果你確實在項目中引入了其中的一個，可維護性可能會更容易，但從它的聲音來看，最初的工作將會比最終值得的工作更多。