DAL層：用存儲過程

Question

應用EF 4.0或普通數據訪問層：

我對將被用來作爲一個產品一箇中大尺寸應用程序的工作，我們需要把我們的DAL層決定。應用程序UI在Silverlight中，DAL層將在服務層後面。我們也在推進域模型，所以我們的數據庫表和域類不具有相同的結構。所以像Data Mapper和Repository這樣的模式肯定會出現。

我需要設計DAL層考慮以下優先的方式提到的因素，發展與技術

性能

的高於平均水平的業績

維護

未來支持和穩定性

1. 速度

限制：

1）我們需要嚴格繼續與微軟，我們不能使用NHibernate的或任何其他的ORM除了EF 4.0

2）我們可以使用任意的代碼生成工具（應該是開源還是很便宜），但它只能在.Net中生成代碼，所以在每個拷貝的基礎上不會有任何授權問題。

問題

1. 我讀到EF 4.0這麼多的文章，在一開始它看起來像它仍然從NHibernate的功能欠缺，但它是相當好，然後EF 1.0

所以，你的人覺得我們應該用EF 4.0先走，還是應該堅持ADO .Net和使用如下代碼史密斯或其他任何你覺得最好的

任何代碼geneartion工具

此外，我需要回答的一樣，如果在未來我們與EF 4.0卡住了某些功能或我們有嚴重的性能問題，它會採取什麼樣的時間端口的應用程序從EF 4.0到ADO淨的問題。

在相反的情況下，如果我們繼續前進，選擇ADO的.Net然後它會採取什麼時間SWITH來到EF 4.0

Lastly..as我正在經歷的文章中，我發現的唯一代碼方法（使用POCO類）似乎最適合我們的要求，因爲從一種技術到其他技術的切換非常容易。

請按同樣分享你的想法，請在上述問題

Answer 1

使用EF4將爲您節省很多手動編碼或代碼生成。這似乎證明了使用它 - 最好的代碼和唯一保證無缺陷的代碼是你不需要編寫的代碼。

EF4和NHibernate等是非常強大的工具，可以處理最苛刻和複雜的業務需求 - 諸如數據庫表中的繼承等等。然而，它們確實會增加一些開銷，而且它們並不總是易於學習和掌握。

所以我的挑釁性問題是：爲什麼不使用Linq-to-SQL？如果你只需要SQL Server作爲後端，如果你的映射在你的域模型中幾乎總是表和類之間的1：1映射，這可能比使用EF4或NHibernate更容易。

Linq-to-SQL絕對比EF4更容易和更快 - 它只是數據庫頂部的一個非常薄的層。這比學習NHibernate容易得多 - 不需要繁瑣的映射語法來學習，你可以通過視覺設計器獲得支持。而且很簡單，您甚至可以進入並使用例如代碼生成操作代碼生成。 T4模板（參見Damien Guard的Linq-to-SQL templates）。

即使在.NET 4/VS 2010中，Linq-to-SQL也是100％支持的，所以在VS2012中（或者下一個被調用的）會有很大的可能性。所以，那些關於它的消亡的世界末日預言在很大程度上被誇大了 - 我不擔心這是第二次的未來證明。

UPDATE：之間的LINQ到SQL和EF一些性能比較：

• Entity Framework and Linq-to-SQL Performance Comparison
• Looking at EF Performance - some surprises
• Entity Framework and LINQ to SQL

一般而言，LINQ到SQL似乎在查詢性能方面具有優勢，但EF似乎在更新上表現更出色。

Answer 2

你從哪裏得到從約束DAL的存儲過程是正常的想法引導？我個人說再見，他們像15年前去然後系統，如市場上任何ORM（興：實體框架是比較喜歡NHibernate的東西AP萊蒂壞的）。我個人總是很抱歉，除了MS「粉絲」之外，所有人都是新鮮事物。

即使有Entity Framework的限制 - 它比任何可以手動使用存儲過程的方法都要好得多。

1：通常約40％到60％的代碼處理數據庫交互。這被任何非愚蠢的ORM消除 - >做數學。

2：參見1.

3：好問題。可悲的是，MS在數據訪問方面有着非常愚蠢的做法。

4：最有可能與您的手寫書一樣 - 在5％以內。可悲的是你的貧血ORM（實體框架）沒有實現任何真正有趣的功能（緩存等），所以休閒收益不會自動實現。