最近在研究ENTITY FRAMEWORK 有一件事不明白

yangwulong1978

我一直都是做那种传统的ＡＤＯ。ＮＥＴ　＋　SQL　ＳＴＯＲＥ　　ＰＲＯＣＥＤＵＲＥ　　来做存数据用的，

现在在看ENTITYＦＲＡＭＥＷＯＲＫ　＋　ＬＩＮＱ。

如果用了，ENTITYＦＲＡＭＥＷＯＲＫ　＋　ＬＩＮＱ　是不是就不需要存储过程了？　

直接在程序里用ＬＩＮＱ查询？

如果，ＥＮＴＩＴＹFRAMEWORK  LINQ 和 STORE PROCEDURE 混合一起用的话，什么情况下用什么？

flyspirit

一般情况下不需要存储过程了， 但有些需要在数据库端实现的逻辑还是放在存储过程里好。 或者由于性能考虑不得不放在数据库端实现的时候。

yangwulong1978

flyspirit 发表于 2012-12-6 10:25
一般情况下不需要存储过程了， 但有些需要在数据库端实现的逻辑还是放在存储过程里好。 或者由于性能考虑不 ...

我个人是认为STORE PROCEDURE 性能会快不少，，ＥＮＴＩＴＹFRAMEWORK 就是在CODE 和 数据库之间夹了层东西，，方便程序员，但是性能，我是没用过，不好说，不过，看现在ENTITY ＦＲＡＭＥＷＯＲＫ微软在推，很多公司也在用，还是学习学习，，

flyspirit

我认为软件系统不是光看performance的。 有很多其他因素考虑， 比如维护性， 扩展性等等都是要考虑的因素。好的设计是在这些需求之间找到平衡点。

Entity Framework等ORM的基本理念是商业逻辑应该在逻辑层这边搞定， 维护性，扩展性都有很大优势。

uowzd01

sp还是要用的，尤其是一些复杂的sp，不可能用linq代替

entity framework直接把sp包装成function了，这样你的context里面就有所有的sp对应的function，直接调用就行

findcaiyzh

我在一个网站上用EF记录用户的Action，就是简单的Add(object).开销大的吓人，估计是用于维护记录的状态了。后来用EF调用Sp，就好了很多很多。给管理员用的management页面用EF就没啥问题了。

yangwulong1978

我现在财务软件，每个用户每天可能都产生几百个，TRANSACTION ，日积月累 都好多万条，，我觉得还是SP 快点，用ＥＮＴＩＴＹFRAMEWORK 调用SP  应该比自己去查询会好很多，

longmurphy

开始用EF的时候，总是有点不太顺手，可能思路还没有从以前转过来，不过也很想知道大家在大量transaction的系统里面是如何用EF的。

flyspirit

真没有必要守着一点performance gain而放弃ORM， 很多情况下performance的影响很小（前提是用对了）。

StackOverflow 这么大的量， 都能够用linq2sql实现， 绝大多数的系统都没问题。

kanjunhai

I am not big fan of EF, if your database is SQLSever, linq2sql is still better choice in my view.

atransformer

大而全的东西，建议少用。

brahmasky

lz也是搞开发的，呵呵，以前没注意到

无视

对这类orm tools，测试环境下要用sql profiler盯着你的database，而且新手很容易误用，DBA那边比较难以通过.

flyspirit

kanjunhai 发表于 2012-12-6 20:13
I am not big fan of EF, if your database is SQLSever, linq2sql is still better choice in my view.

LINQ2SQL is almost dead.

joerkky

EF的确很方便，但是效率低的惊人。EF的逻辑是Persistence Ignorance, 就是你操作你的POCO就好了，不用管SELECT, INSERT, UPDATE，所以business logic和persistence logic很完美的分开了。

ADO.NET + SP跟EF是两个极端，ADO.NET +SP你知道什么时候存，什么时候取，因为这些都得你自己实现。如果实现的不好的话会很messy, 如果实现的好的话也可以把business logic和persistence logic分开。SP还有个好处就是安全性。如果你完全用SP实现的话，数据库就可以只赋给EXECUTE权限，更安全。

对于中小型项目来说，个人觉得还是Micro ORMs最适合，比如PetaPoco啊什么的。基本上就是ADO.NET + Mapping, 对大多数情况足够了。

我自己写了一个Micro ORM, 本来是用在公司项目里的，但是觉得挺好用就放GITHUB了。文档还没来的及写，感兴趣的童鞋自己看看吧，有问题的话QQ 331633199

没权限发链接，大家自己手工转格式吧
https%3A%2F%2Fgithub.com%2Fz-george-ma%2FSimpleADO

wil

flyspirit 发表于 2012-12-6 19:00
真没有必要守着一点performance gain而放弃ORM， 很多情况下performance的影响很小（前提是用对了）。

S ...

没这么简单吧

典

如果ADO.net + SP
请问Transaction 应该在哪边做？

可不可以C# 和 数据库里都使用transaction?

joerkky

这个问题要看是什么上下文了。

比如说用户下订单，需要进行两个操作，保存订单和更新存货量。如果是个很简单的系统，你把这两个操作写到一个SP里面去没啥问题。但如果这两个操作都很复杂，似乎就应该用unit of work了。

thinkriver

从EF1开始就在边学边用了，现在已经到Entity Framework 5，不过EF其实没有2，3，版本直接跳到4， EF5 已经对性能做和很多优化，在开发中的EF 6有更多优化。

对于使用EF的时候，是需要开发人员多了解EF的执行原理，做好query warm up和cache, 在多数情况下，对于一般的操作来说，使用EF可以加快开发效率，性能方面，如果做好优化，效果还是可以接受的，毕竟对于系统的维护和扩展有很大好处。对于性能，写好LINQ to Entity才是最关键的，而写好Linq2Entity，还需要对SQL有一定程度的了解，否则还是会搞的性能还不好。很多时候EF执行效率不好，很因为Linq2Entity query写的不好。如果还想接近底层的查询，可以写Entity SQL，或者直接执行SQL。

如果说是处理数据的比较繁重的逻辑部分，调用SP还是好的选择。现在用DBContext调用SP也非常简单方便了。而且可以直接将返回的Set封装。

这个问题没有必要选择谁，抛弃谁，在合适的地方用合适的工具，才是正确的选择。EF是工具，用来帮助我们解决问题，而不是用来主宰我们的开发方式。

Linq2SQL已经淡出了。

目前在EF5，有这么几种选择:
1. 已经有数据库： POCO+DBContext API
2. 没有数据库，如果你熟悉Code First，那就可以用Code First方式。如果不熟悉或者不习惯的话，可以先建立数据库，再用POCO+DBContext
POCO+DBContext还是比较适合用来做DDD的，分离Repostory和Model.

EF5 已经开源了，看源代码是最好的学习方式了。

清风拂山岗

这基本是有定论的东西，再讨论下去意义不大。还是好好看看Martin Fowler写的关于ORM的文章吧。

flyspirit

清风拂山岗 发表于 2012-12-8 12:22
这基本是有定论的东西，再讨论下去意义不大。还是好好看看Martin Fowler写的关于ORM的文章吧。 ...

楼上是指这篇吧

ORMHate  http://martinfowler.com/bliki/OrmHate.html

清风拂山岗

Yes, that's the article I referred to. I have been using ORM for more than 6 years now, what he said in the article corresponds with my experience.

thinkriver

Essentially the ORM can handle about 80-90% of the mapping problems, but that last chunk always needs careful work by somebody who really understands how a relational database works.

This is where the criticism comes that ORM is a leaky abstraction. This is true, but isn't necessarily a reason to avoid them. Mapping to a relational database involves lots of repetitive, boiler-plate code. A framework that allows me to avoid 80% of that is worthwhile even if it is only 80%

这其实就是使用ORM的根本，不是说有了ORM就是万事大吉了。最重要的是，还得开发人员了解它，知道它长处和短处，并进而善加利用。最近在看MR的那本名著，这哥们真是个天才啊...

kanjunhai

flyspirit 发表于 2012-12-7 09:50
LINQ2SQL is almost dead.

LINQ2SQL is still a better choice compare to EF if your db is SQL server.

huaxianz

joerkky 发表于 2012-12-7 16:58
这个问题要看是什么上下文了。

比如说用户下订单，需要进行两个操作，保存订单和更新存货量。如果是个很简 ...

没错。
很多商业领域的business transaction,需要几天甚至个把星期才能完成，比如amazon的订单整个lifetime，单纯用database transaction不可能实现。如果是纯sql server的环境，我建议用service broker来实现，非常高效。如果是混搭环境，就要用更为专业的整合系统比如BizTalk。自己实现过于复杂。

smbk

你要愿意的换，依然可以用原来的sp，而且用sp有它的好处，性能上通常也略微快一点点，尽管通常这种性能差异都被忽略了。