對於小型企業應用程序而言，實體框架是否會顯得過大？

Question

我正在為特定行業的小型企業中創建C＃/ SqlServer應用程序。 它是對具有近100個數據庫表的VB6應用程序的重寫。 它不像某些應用程序那樣位於更大的企業應用程序和數據庫企業結構中。 它是獨立的，將只有大約1-3個開發人員在使用它。

對於這樣的應用程序，實體框架會否成為過大殺傷力？ 我正在尋找至少一個微型ORM來簡化應用程序的數據訪問部分，但是功能齊全的ORM是否會過大？

編輯：我會認為ORM在很大程度上適合較大的開發環境。

Answer 1

EF是否“過度殺傷”完全取決於上下文。 確實，您提到了“以后很繁重”，但是在很多方面與 “小型企業應用程序” 無關 ，因為您永遠不會承受它的沉重負擔。 然后，您甚至可能會爭辯說， 除了使用ORM之外， 任何其他事情都是過大的（因為這會增加開發工作）。

您還提到了微型ORM； 確實，它們將減少大量的ADO.NET原始代碼（您在注釋中列出了這些代碼）。 Simple.Data提供了一個很好的抽象層，也不需要編寫TSQL-可能不是一個壞的起點，但是有了100個表，我可以看到EF / L2S / etc的許多吸引人的方面（尤其是對於存根而言）清除所有對象）。 但是，EF 本身確實具有許多“功能”（意思是：用腳尖踢的地方），這意味着您仍然需要學習EF的工作原理。 所有抽象總是在某種程度上做到這一點 -因此，要權衡此成本與手動執行的成本。

Answer 2

絕對不是矯kill過正。

在我的工作場所中，我們使用EF4.1或我們自己的ORM。 它確實加快了開發速度，避免了您編寫粘合代碼將行映射到實例。

我們僅在以下情況下使用SQL

• 性能勝過代碼的可讀性/可維護性
• 我們有ORM無法處理的查詢

Answer 3

僅當您這樣感覺時，ORM才算是過大殺傷力。 有一百張桌子，看起來很合理。

您可能更喜歡一些微型ORM（例如SimpleData或Massive ），但這取決於您：當EF強制進行強類型鍵入時，微型Orm可能會與數據庫失去太多的聯系。