我正在启动一个基于ASP.NET和Windows服务器的新项目。
该应用程序计划非常庞大，为大量客户提供拉取和更新高频率变化数据的服务。
我先前使用Linq-To-Sql或Ado.Net创建过项目。
我的计划是在此项目中使用VS2010和新的EF4框架。
很想听听其他程序员对使用Entity Framework进行开发的看法。
从以前的经验中得出的优缺点是什么？
你认为EF4已经可以投入生产了吗？
- 我应该冒险尝试还是坚持老实可靠的ADO.NET？
ADO.NET实体框架或ADO.NET
7
- RuSh
1
你能多说一些关于那个应用程序的信息吗？听起来像是一个交易应用程序 - 不好的消息是：完全错误的工具。 - TomTom
3个回答
6
EF4是否真的适合生产还有点难说，因为它还没有正式发布...但是所有初步的经验和报告都表明它非常好。但是需要考虑EF要解决的问题；它是一种双层方法，一层映射到数据库中的物理存储模式（并支持多个后端），第二层是您编写程序的概念模型。当然，这两个层之间需要进行映射。因此，如果您有大量的表格，需要支持多个后端，需要能够将物理模式映射到不同的概念模式等等，则EF4非常适合。它非常适合复杂的企业级应用程序。但是这是有代价的-这些额外的层确实会影响性能、复杂性和可维护性。如果您需要这些功能，您会乐意支付这个代价，毫无疑问。但是您真的需要吗？当然，您可以回到直接使用ADO.NET，但是您真的想再次处理DataTables、DataRows和未经类型化的Row["RowName"]构造吗？所以我的建议是：
如果您只需要 SQL Server 作为后端，如果您的模型中有一个数据库表与一个实体对象的相对简单和直接的映射，则使用 Linq-to-SQL！为什么不呢？它在 .NET 4 中仍然得到了 Microsoft 的全力支持 - 哪怕他们还做了一些错误修复和添加了一些功能 - 它快速、高效、精简而且高效，所以为什么不用呢？
如果您只需要 SQL Server 作为后端，如果您的模型中有一个数据库表与一个实体对象的相对简单和直接的映射，则使用 Linq-to-SQL！为什么不呢？它在 .NET 4 中仍然得到了 Microsoft 的全力支持 - 哪怕他们还做了一些错误修复和添加了一些功能 - 它快速、高效、精简而且高效，所以为什么不用呢？
- marc_s
7
1EF是未来 - 如果你需要所有这些功能，那么是的。Linq-to-SQL可用，它有效，它工作得很好，它很快 - 为什么不使用它呢？ - marc_s
1你是否仍然坚持在新项目中使用 Linq To SQL，以便在 1-1 映射中暴露表格，并且可能会使用 WCF 数据服务？谢谢！ - Nock
1@Nock：随着Entity Framework（4.0-4.3版本和Code-First方法）的最新进展，Linq-to-SQL失去了越来越多的优势。今天我可能会选择EF 4.x而不是Linq-to-SQL。 - marc_s
@Nock：是的，非常接近了，如果不是更好（EF使用一些更先进的优化技术来为某些情况生成比Linq-to-SQL更好的SQL语句）。 - marc_s
1@Nock +1 为检查 marc_s 的意见，向 marc_s 致敬，因为他完全改变了他之前（3年前）的评论。事情在变化。感谢您维护最新的 SO。 - Robino
显示剩余2条评论
2
我的建议是两者都使用。起初，我认为我只会使用linq to sql，再也不用接触ado.net了（这让我很高兴lol）。
现在我两个都在用，因为有些事情linq to sql（和任何ORM，如EF）无法完成。我必须进行一些大量插入的操作，首先我使用linq to sql，对于500条记录，需要超过6分钟才能完成（其中2分钟用于验证规则，其余时间用于插入到数据库中）。
我改用sql bulk copy，现在只需要2分4秒就可以完成所有插入（4秒钟完成所有插入）。
但正如marc_s所说，我真的不想去处理DataTables、DataRows和未经过类型定义的Row [“RowName”]。
假设我的表有10列，名为Table A。我使用linq to sql并创建了一个Table A类（new TableA()）对象并填充了数据。然后我将此对象传递给一个方法，该方法创建了datarow。
因此，linq to sql节省了我一些时间，因为我可能会制作一个类，因为我不想将10个参数传递到创建数据行的方法中。我还觉得它会带回一点类型感，因为您必须传递正确的对象才能使用该方法，因此传递错误数据的机会较小。
最后，您仍然可以使用linq to sql调用存储过程，这就像一行代码。
因此，每当您注意到linq to sql（或在您的情况下EF）很慢时，只需编写一个SP并通过EF调用它即可。如果需要直接使用ado.net，请评估您需要做什么，也许您可以使用EF来完成大部分代码（因此至少可以使用对象进行工作），并且仅针对该小部分ado.net，就像我使用sql bulk copy所做的那样。
现在我两个都在用，因为有些事情linq to sql（和任何ORM，如EF）无法完成。我必须进行一些大量插入的操作，首先我使用linq to sql，对于500条记录，需要超过6分钟才能完成（其中2分钟用于验证规则，其余时间用于插入到数据库中）。
我改用sql bulk copy，现在只需要2分4秒就可以完成所有插入（4秒钟完成所有插入）。
但正如marc_s所说，我真的不想去处理DataTables、DataRows和未经过类型定义的Row [“RowName”]。
假设我的表有10列，名为Table A。我使用linq to sql并创建了一个Table A类（new TableA()）对象并填充了数据。然后我将此对象传递给一个方法，该方法创建了datarow。
因此，linq to sql节省了我一些时间，因为我可能会制作一个类，因为我不想将10个参数传递到创建数据行的方法中。我还觉得它会带回一点类型感，因为您必须传递正确的对象才能使用该方法，因此传递错误数据的机会较小。
最后，您仍然可以使用linq to sql调用存储过程，这就像一行代码。
因此，每当您注意到linq to sql（或在您的情况下EF）很慢时，只需编写一个SP并通过EF调用它即可。如果需要直接使用ado.net，请评估您需要做什么，也许您可以使用EF来完成大部分代码（因此至少可以使用对象进行工作），并且仅针对该小部分ado.net，就像我使用sql bulk copy所做的那样。
- chobo2
0
EF 4现在更类似于LINQ to SQL，好处是它将FK键正确地放置在对象中，将添加方法放置在对象集中，并具有许多其他不错的功能。设计器得到了很大的改进，最重要的是它可以与SQL和Oracle一起使用，也许还支持其他一些提供程序（只要提供程序支持）。而不像LINQ to SQL仅支持SQL Server。
EF是未来的趋势；ADO.NET数据服务是一个Web服务附加组件，此外它还支持POCO和T4生成，任何新功能都将支持此功能（LINQ to SQL仅维护，数据集将不再进行任何更改）。
希望对你有所帮助。
- Brian Mains
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接