ADO.NET实体框架或ADO.NET

Question

我正在启动一个基于ASP.NET和Windows 的新项目。

该应用程序计划相当大，服务于大量客户端，拉动和更新高freq。更改数据.

我以前用Linq或Ado.Net创建了项目。

我计划使用VS2010和新的EF4框架.。

• 如果能听到其他程序员关于实体框架开发的选择，那就太好了
• 以往经验的利弊？
• 你认为EF4已经准备好投入生产了吗？
• 我是应该冒这个险，还是干脆坚持过去的好ADO.NET？

Answer 1

EF4是否真的准备好生产还很难说，因为它还没有正式发布.但所有的初步经验和报告似乎表明，它是相当好的。

但是:您需要考虑EF试图解决的问题；它是一种两层方法，一层映射到数据库中的物理存储模式(并且支持多个后端)，第二层是您针对的概念模型。当然，需要在这两个层之间进行映射。

因此，如果您有大量的表，如果您有多个要支持的后端，如果您需要能够将一个物理模式映射到一个不同的概念模式，那么EF4是很好的。对于复杂的企业级应用程序来说，这是很棒的。

但这是要付出代价的--这些额外的层确实会对性能、复杂性和可维护性产生影响。毫无疑问，如果你需要这些功能，你会很乐意为此付出代价的。但你需要那个吗？

当然，您可以回到直接的ADO.NET --但是您真的想再一次摆弄DataTables、DataRows和非类型化的Row["RowName"]构造吗？真的？

所以我的建议是：

• 如果只需要SQL Server作为后端
• 如果您的模型中有一个数据库表到一个实体对象的简单直观的映射

然后:使用Linq到SQL！为什么不行？?微软在.NET 4中仍然完全支持它--他们甚至使用了修正并增加了一些零碎 --它速度快、效率高、精益、吝啬--那为什么不呢？

Answer 2

我的建议是两者兼用。一开始，我以为我只会使用linq来进行sql，以后再也不用碰ado.net了(是什么让我很开心的)。

现在我使用这两种方法，因为linq到sql(以及任何ORM (如EF) )都做不到。我不得不做一些大量的插入，我首先使用linq到sql并完成500条记录，花费了6分钟(2分钟用于验证规则rest插入到db中)。

我将其改为sql大容量复制，现在它已降至2分4秒(执行所有插入的时间为4秒)。

但就像marc_s说的那样，我真的不想摆弄DataTables、DataRows和未输入的行“RowName”。

假设我的表长为10列，名为表A。我所做的是使用linq对sql进行sql，并创建了一个表A类(新的TableA())对象，并将其填充到数据中。然后，我将这个对象传递给一个创建datarow的方法。

所以linq到sql节省了一些时间，因为我可能会创建一个类，因为我不希望将10个参数传递到生成数据行的方法中。我还觉得它提供了一些类型性，因为您必须传递正确的对象才能使用该方法，因此传递错误数据的可能性更小。

最后，您仍然可以使用linq到sql来调用存储过程，这就像一行代码。

因此，当您注意到linq (或者在您的例子中是EF)很慢时，我会使用这两种方法，然后编写一个SP并通过EF调用它。如果您需要直接执行ado.net，那么评估您需要做的事情，也许您可以在大部分代码中使用EF (因此您至少可以使用对象)，并且只用于我对sql副本所做的小部分ado.net。

Answer 3

在好的方面，EF 4现在更类似于LINQ；它在对象中有FK键，在对象集中有add，还有许多其他好的特性。THe设计器有了很大的改进，主要优点是它可以使用SQL和Oracle，或者其他一些(只要提供程序支持它)，而不是只使用Server的LINQ。

EF是未来的趋势；ADO.NET数据服务是一个web服务添加，而且它支持POCO和T4生成，任何新特性都将支持这一点(LINQ仅用于维护，数据集将不再有任何更改)。

HTH。