我應該堅持實體框架嗎？

我在新的互聯網網絡應用程序中採用了EF（.NET 4.5以上版本）。我應該堅持實體框架嗎？

這個應用程序確實涉及到數據庫活動的一些操作，並涉及大約30個或更多的表。

我的觀點是這不是一個簡單的學校項目，EF通常適合大多數需求。

進一步我開發這個應用程序，我發現EF非常有限或禁止進行適當/好分貝的設計（尤其是在性能方面）

1）包括

我遇到包括特徵查詢部分。缺少許多數據是由於缺少包含設置。

我把這個東西放得越多，我越擔心一個簡單的數據檢索就是在某些功能上獲得比我需要的更多的東西。

2）驗證

我採用流利驗證了這方面的需要，因爲我更喜歡訪問者模式，在需要的地方過來的數據代碼本身沒有直接的代碼更改。

但隨着我繼承我越來越挑戰，我需要鍛鍊驗證能夠尊重面向對象的簡單的東西。我管理它，雖然更復雜，我真的不喜歡它的實現某些東西。我相信這個子類驗證問題也發生在DataAnnotation中。

3）交易

現在，我需要把適當的分貝transactaction控制，我發現這個缺乏EF，糾正我，如果我錯了。

我曾經使用過Enterprise組件（.NET中的COM +，很久以前），並且我在EF中找不到合適的（或缺少它）事務實現。

我還在這方面的工作...

結論）

我體會到英孚已經幫助我在我的編碼的唯一的事情，是數據/實體代碼生成，這這是這是許多其他工具/框架的共同特徵。

我在考慮放棄這個EF，切換回pre-EF時代方法，採用存儲過程，仍然是代碼生成的表類（但不是EF或DBML）。

我可以不使用SQL LINQ，因爲在過去的性能問題上我有很多挑戰。

我喜歡你的觀點，我應該留下來堅持EF，無論出於何種原因，我簡單的頭腦可以感知到，除了這個ORM，它幾乎不切實際地工作。

來源

2013-07-15 Kelmen

使用EF 6中的事務處理：https：//msdn.microsoft.com/en-us/data/dn456843.aspx –

你看過Dapper嗎？ Dapper是一個超快的微型ORM。它是由Stackoverflow人（Sam Saffron）開發的，他們在本站廣泛使用它，原因是您提到的原因 - 性能和速度。這裏是鏈接：

https://github.com/StackExchange/dapper-dot-net。

我們放棄了EF，我們只使用Dapper。結合Dapper.SimpleCRUD和Dapper.SimpleCRUD.ModelGenerator等其他社區開發的Dapper擴展，我們可以快速從數據庫生成POCO，同時保留Dapper對EF的所有優勢。總的來說，你會寫更多的代碼，但Dapper的速度幾乎等同於使用ADO.NET的SqlDataReader。這裏有一個鏈接到SimpleCRUD：

https://github.com/ericdc1/Dapper.SimpleCRUD/

來源

2013-07-15 07:49:20 Marko

我會問，如果Dapper實際上是ORM。它甚至呈現爲對象映射器而不是全功能的ORM。 – Euphoric

我一直在嘗試採用Dapper，但最後也放棄了。我真的不喜歡它如何檢索/查詢數據。傾向於使用LINQ方式。 – Kelmen

這裏沒有1個打孔解決方案。是的，如果你使用EF，你不必知道SQL，因爲你可以使用LINQ，而EF會將你的LINQ轉換成SQL查詢。但是，這種翻譯有成本，成本是時間。另一方面，Dapper會讓你編寫更多的代碼，並且你必須知道SQL，但是你只會在應用程序中編寫你需要的東西。 – Marko

我同意EF是那麼有用，當你超過一定階段

如果你的數據庫是非常有用的超出你的應用程序，然後設計DB爲您的企業，而不僅僅是你的申請。這是EF掉下來的地方。它沒有（不能）考慮到其他需要的數據庫上的不同觀點，所以你最終得到了天真的索引和關係。

我2C（快速響應一個非常複雜的問題）：

寫的SP（是的，我知道）來管理數據的採集，爲您的業務層提供有用的數據集，並允許插入/更新到您的基礎表。確保你寫了一個有用的數據API，但不要爲每個表格寫CRUD。這是毫無意義的浪費時間。

使用EF掛鉤到這些SP中。 EF生成有用的數據類，給你一個事務包裝器和其他有用的位bobs。

享受！

沒有人會做任何事情 - 挑選&根據情況選擇。

來源

2013-07-15 08:17:23 LoztInSpace

這是什麼EF事務包裝？你能明確地管理它嗎？ – Kelmen

就是這樣的東西。我真的沒有真正的術語http://msdn.microsoft.com/en-us/library/vstudio/bb896325(v=vs.100).aspx真的不那麼令人興奮，但它工作得很好。 – LoztInSpace

什麼是「SP」？ –

說實話，我幾年前還是會建議任何.net/sql新手去EF，因爲linq語法，它看起來很性感...... 但是就這些而言。誠實地說，沒有任何其他的東西可以從EF中獲得。

我知道編寫C＃代替SQL的誘惑聽起來很有用，但事實上並非如此。沒有機器生成的sql可以擊敗手工製作的SQl野獸，你最終在一天結束時:) :)

除此之外，EF只是吃了內存，這是網絡服務器的內存和CPU，在大多數情況下，我認爲，但不確定。儘管如此，它在性能和內存方面消耗更多資源。

我完全厭倦了沉重的重20磅EDMX模型GUI的耳朵。每桌+1磅:)鬆動這麼多時間讓edmx與實際的數據庫保持同步，究竟是什麼原因？誰說你需要VS中所有色彩豐富的圖標，真的嗎？所有這些東西都只是爲了一個，也是唯一的原因 - 讓linq-to-entities成爲可能。爲了避免這種情況，我只是發現原始的SQL看起來不那麼好或很酷。

所以，我自己做出了一段時間的決定 - 沒有EF爲我的個人項目。沒有繁重的越野車事情，生活很容易，當你採取和簡化。

來源

2014-11-21 18:53:25

使用C＃sql的好處對於動態sql非常有用。使用傳統SQL手寫編碼的是一場噩夢。 – Kelmen

@Kelmen這是你的意見。 –

好處不僅僅是「你不需要知道SQL」，你也可以避免繁瑣的代碼編寫，編譯時檢查可以減少很多錯誤的風險。顯然存在權衡，但你的比較是從虛假的前提開始的。 EF本身所消耗的資源並不是那麼重要，最大的代價是，如果每個人都是手動調整的，那麼它所寫的查詢效率就不如他們所能達到的那麼高。 – Casey

我有自己的數據訪問層，使用服務堆棧的ORMlite和toptensoftware的PetaPoco創建。

ORMlite：

1）從C＃類，包括關係，約束等創建表。（CodeFirst）

2）可以做的插入，刪除，更新等。

示例 - 創建表：Employee.EnsureTable（）

Petapoco：

提供者很棒的SQL包裝類，我用它代替linq

例如：sql.Select（「FirstName，LastName」）。From（「Employee」）。Where（「ID = @ 0」，100） .AND（「Active = @ 0」，1）

我比LINQ更喜歡以上風格。這也支持Joins（Cool right？）

目前ORM lite不是免費的。但是你可以得到免費的舊版本。

例子：

//Creating Entity Class 

public class Employee:DatabaseEntity<Employee> 
{ 
    //Define properties 
} 

//DatabaseEntity is my own base class which provides many helper methods from ORM lite and Petapoco, including many static methods eg:EnsureTable() 

//Creating Table 

Employee.EnsureTable() 

//Adding new entity 
Employee e=new Employee(); 
e.FirstName="Chola" 
e.LastName="Raja" 
e.Active=true 
e.Save() 

//Find an employee 
e=Employee.FirstOrDefault(x=>x.ID==101 && x.Active==true); 
//OR 
e=Employee.QuerySingle(sql.Select("FirstName,LastName").From("Employee").Where("[email protected]",100).AND("[email protected]",1)) 

//update 
e.LastName="Raja" 
e.Save() 

//Delete a entity 
e.Delete() 

//Transaction 
e.AssignProject(project1) //this method could do many operation on many entities using Transaction scope

注：我無法從我的項目中提取的代碼。但您可以根據您的要求創建您自己的基類

來源

2015-09-28 12:21:02 CreativeManix

我應該堅持實體框架嗎？

回答

相關問題