ADO.NET 实体框架或 ADO.NET
我正在启动一个基于ASP.NET 和 Windows 服务器的新项目。
该应用程序计划相当大，并为大量客户端提供高频拉取和更新服务。更改数据。
我之前曾使用 Linq-To-Sql 或 Ado.Net 创建过项目。
我对此项目的计划是使用 VS2010 和新的 EF4 框架。
-
很高兴听到其他消息 程序员关于开发的选择 使用实体框架
与之前的优点和缺点 经验？
-
您认为 EF4 已经准备好了吗？ 生产？
- 我应该冒险还是坚持使用普通的老式 ADO.NET？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
EF4 是否真的准备好投入生产还很难说，因为它还没有正式发布……但是所有关于它的初步经验和报告似乎都表明它相当不错。
但是：您需要考虑 EF 想要解决的问题；它是一种两层方法，一层映射到数据库中的物理存储模式（并支持多个后端），第二层是您编程所针对的概念模型。当然，这两层之间需要映射。
因此，如果您有大量表、需要支持多个后端、需要能够将物理模式映射到不同的概念模式等等，那么 EF4 就非常有用。它非常适合复杂的企业级应用程序。
但这是有代价的——这些额外的层确实会对性能、复杂性和可维护性产生影响。如果您需要这些功能，毫无疑问您会很乐意支付这个价格。但你需要那个吗？
当然，您可以直接回到 ADO.NET - 但您真的想再次摆弄 DataTables、DataRows 和非类型化
Row["RowName"]构造吗？真的吗？？？所以我的建议是：
那么：使用 Linq-to-SQL！为什么不呢？ Microsoft 在 .NET 4 中仍然完全支持它 - 哎呀，他们甚至做到了 错误修复并添加了一些零碎内容 - 它快速、高效、精简且简单 - 那么为什么不呢？
Whether EF4 is really ready for production is a bit hard to say since it's not officially been released yet.... but all the preliminary experiences and reports about it seem to indicate it's quite good.
However: you need to take into consideration what EF is trying to solve; it's a two-layer approach, one layer maps to your physical storage schema in your database (and supports multiple backends), and the second layer is your conceptual model you program against. And of course, there's the need for a mapping between those two layers.
So EF4 is great if you have a large number of tables, if you have multiple backends to support, if you need to be able to map a physical schema to a different conceptual schema, and so forth. It's great for complex enterprise level applications.
BUT that comes at a cost - those extra layers do have an impact on performance, complexity, maintainability. If you need those features, you'll be happy to pay that price, no question. But do you need that??
Sure, you could go back to straight ADO.NET - but do you really want to fiddle around with DataTables, DataRows, and untyped
Row["RowName"]constructs again?? REALLY???So my recommendation would be this:
then: use Linq-to-SQL ! Why not?? It's still totally supported by Microsoft in .NET 4 - heck, they even did bugfixes and added a few bits and pieces - it's fast, it's efficient, it's lean and mean - so why not??
我的建议是两者都使用。起初我以为我只会使用 linq to sql 而不必再接触 ado.net （这让我很高兴哈哈）。
现在我同时使用两者，因为有些事情 linq to sql（以及任何 ORM，如 EF）无法完成。我必须进行一些批量插入，我首先使用 linq to sql 进行操作，并执行 500 条记录，花费了超过 6 分钟（验证规则需要 2 分钟，其余的则插入到数据库中）。
我将其更改为 sql 批量复制，现在减少到 2 分钟 4 秒（4 秒完成所有插入）
但是就像 marc_s 所说的那样，我真的不想摆弄 DataTables、DataRows 和非类型化 Row["RowName"] 。
假设我的表大约有 10 列长，称为表 A。我所做的是使用 linq to sql 并创建一个表 A 类（new TableA()）对象并用数据填充它。然后，我将该对象传递给创建数据行的方法。
所以 linq to sql 节省了我一些时间，因为我可能会创建一个类，因为我不想将 10 个参数传递到生成数据行的方法中。我还觉得它提供了一些类型性，因为您必须传递正确的对象才能使用该方法，因此传递错误数据的机会更少。
最后，您仍然可以使用 linq to sql 来调用存储过程，就像一行代码一样。
因此，当您注意到 linq to sql（或在您的情况下为 EF）速度很慢时，我会同时使用这两种方法，然后只需编写一个 SP 并通过 EF 调用它即可。如果您需要直接 ado.net 评估您需要做的事情，也许您可以将 EF 用于大部分代码（这样您至少可以使用对象），并且仅对一小部分 ado.net 执行我所做的操作sql批量复制。
My advice is use both. At first I thought I would only use linq to sql and never have to touch ado.net ever again ( what made me happy lol).
Now I am using both because some things linq to sql(and any ORM like EF) can't do. I had to do some mass inserts and I did it first with linq to sql and to do 500 records it took over 6mins(2 mins for validation rules rest was inserting into the db).
I changed it to sql bulk copy and now it is down to 2min and 4 seconds(4 seconds to do all inserts)
But like marc_s said I really did not want to fiddle around with DataTables, DataRows, and untyped Row["RowName"].
Say my table was like 10 columns long and called Table A. What I did was I used linq to sql and made a Table A class( new TableA()) object and populated it with data. I then would pass this object to a method that created the datarow.
So linq to sql saved me some time because I probably would have made a class as I would not have wanted to pass in 10 parameters into the method that makes the data row. I also feel it gives a bit of typeness back as you have to pass in the right object to use that method so less chance of passing in the wrong data.
Finally you can still use linq to sql to call Stored procedures and that is like one line of code.
So I would use both when ever you notice that linq to sql (or in your case EF) is slow then just write a SP and call it through EF. If you need to do straight ado.net evaluate what you need to do maybe you can use EF for most of the code(so you can at least work with objects) and only for that small portion ado.net sort of what I did with sql bulk copy.
EF 4 现在在好的方面与 LINQ to SQL 更加相似；它在对象中具有 FK 键，在对象集中具有添加方法，以及许多其他不错的功能。设计器得到了很大的改进，主要优点是它可以与 SQL 和 Oracle 一起使用，也许还有其他一些（只要提供程序支持它），而不是仅与 SQL Server 一起使用 LINQ to SQL。
EF就是未来； ADO.NET 数据服务是一个 Web 服务附加组件，此外它还支持 POCO 和 T4 生成，任何新功能都将支持这一点（LINQ to SQL 只是维护，数据集不会再进行任何更改）。
HTH。
EF 4 is now more similar to LINQ to SQL, in the good ways; it has the FK keys right in the object, has add methods right in the object sets, and a lot of other nice features. THe designer is much improved, and the major plus is that it works with SQL and Oracle, and maybe some others (as long as the provider supports it) instead of LINQ to SQL with only SQL Server.
EF is the future; the ADO.NET data services is a web service add on, plus it supports POCO and T4 generation, and any new features will support this (LINQ to SQL is maintenance only, and data sets won't be getting any changes any more).
HTH.