10

I adopted EF (out of box of .NET 4.5) in my new internet web app.

this app do involve quite some operation over db activities, and involve around 30 or more tables.

my point is this is not a simple school project, where EF typically suit for most needs.

as further I developing this app, I found EF very limited or prohibitive for proper/good db design (especially in term over performance)

1) Include

I encountering the Include feature in the query part. Many data missing is due to missing include setting.

the more I putting in this thing, the more I worry a simple data retrieval is getting more things than I needed in certain function.

2) Validation

I'm adopting Fluent Validation for this need, as I prefer the visitor pattern, where no direct code changes needed over the data code itself.

but then I getting more challenges as I subclassing, I need to workout validation able to respect OOP simple stuff. I managed it, though more complexity and certain things I really dislike in its implementation. I believe this subclass validation issue happened in DataAnnotation as well.

3) Transaction

Now, I need to incorporate proper db transactaction control, and I found this lacking in EF, correct me if I'm wrong.

I used to worked with Enterprise component (COM+ in .NET, long-long time ago), and I can't find the proper (or the lack of it) transaction implementation in EF.

I'm still working on this...

concluding)

I come to realize the only thing EF has helped me in my coding, is the data/entity code generation, which this is common feature over many other tool/framework.

I'm thinking to drop this EF, switch back to pre-EF era approach, adopting stored-proc, still code-generated table class (but not EF or DBML).

I can do without SQL LINQ, as I have many challenges over this in past over performance issue.

I like your opinion that I should stay and stick to EF, for whatever reason that my simple mind can perceive, apart from this ORM, which hardly is realistically working at all.

4

4 回答 4

9

你有没有研究过Dapper？Dapper 是一个超快的微型 ORM。它是由 Stackoverflow 的人 (Sam Saffron) 开发的，他们在这个网站上广泛使用它，正是出于你提到的原因 - 性能和速度。链接在这里：

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

我们放弃了 EF，只使用 Dapper。结合其他一些社区开发的 Dapper 扩展，如 Dapper.SimpleCRUD 和 Dapper.SimpleCRUD.ModelGenerator，我们可以从数据库快速生成 POCO，同时保留 Dapper 优于 EF 的所有优势。总的来说，您将编写更多代码，但 Dapper 的速度几乎等同于使用 ADO.NET 的 SqlDataReader。这是 SimpleCRUD 的链接：

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

于 2013-07-15T07:49:20.163 回答
2

我同意当您超过某个阶段时，EF 的用处不大

如果您的数据库在您的应用程序之外有用，那么为您的企业设计数据库，而不仅仅是您的应用程序。这就是EF下降的地方。它没有（不能）考虑其他需要的玩家对数据库的不同观点，因此您最终会得到幼稚的索引和关系。

我的 2c（快速回答一个非常复杂的问题）：

编写 SP（是的，我知道）来管理数据收集，为您的业务层提供有用的数据集并允许插入/更新您的基础表。确保你编写了一个有用的数据 API，不要只为每个表编写 CRUD。那是毫无意义的浪费时间。

使用 EF 连接到这些 SP。EF 生成有用的数据类，为您提供事务包装器和许多其他有用的东西。

享受！

没有一种工具可以做所有事情——根据情况进行挑选。

于 2013-07-15T08:17:23.613 回答
0

To be honest, I few years ago I'd still suggest any .net/sql newcomer to go with EF because of the linq syntax, it looks sexy... But that's all about it. There's honestly nothing else you may ever gain from EF.

I know that the temptation of writing C# instead of SQL might sound very useful at the beginning but in fact it's not. No machine-generated sql can ever beat handcrafted piece of SQl beast you end up having at the end of the day :)

Other than that, EF is just eating the memory which is the web server's memory and CPU ,well, in most cases I think, but not sure. Still, it's consuming way more resources performancewise and memorywise.

And I'm entirely fed up to the ears with the heavy heavy 20 pound edmx model GUI. +1 pound for every table :) Loosing so much time keeping the edmx in sync with the actual DB, and what reason for after all? Who said you need all that colorful icons for your tables in VS, really? All that stuff is there just for one and the only reason - to make linq-to-entities possible. To hell with it, I just find original SQL looking in no way less nice or cool.

So, I myself made a decision some time ago - no EF for my personal projects. No heavy buggy stuff, life's easy when you're taking and making it easy.

于 2014-11-21T18:53:25.890 回答
0

我使用 Service stack 的 ORMlite 和 toptensoftware 的 PetaPoco 创建了自己的数据访问层。

ORMlite：

1) 从 C# 类创建表，包括关系、约束等。 (CodeFirst)

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

示例 - 创建表：Employee.EnsureTable()

佩塔波科：

Providers 很棒的 SQL 包装类，我用这个代替 linq

例如： sql.Select("FirstName,LastName").From("Employee").Where("ID=@0",100).AND("Active=@0",1)

我更喜欢上述风格而不是 LINQ。这也支持加入（很酷吧？）

目前 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("ID=@0",100).AND("Active=@0",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-28T12:21:02.883 回答