ADO.NET实体框架:ORM解决方案之间的决策 [英] ADO.NET Entity Framework: Decision Making between ORM solutions
问题描述
在选择ORM时，我正在为我的新应用程序寻找一些准则.我想通过NHibernate和LINQ to SQL评估EF.我需要来自这个美好社区的专家声音. 您可以在以下几点进行评估.
- 可扩展性
- 学习曲线
- 易于使用
- 性能 ETC.
在您列出的三个中，NHibernate的使用时间最长.如果您想使用具有可靠记录的产品，那可能是一个安全的起点.
即使在四个指标(规模/学习曲线/易用性和性能)上，它的表现也相当不错，尽管您可能会发现由于它比其他两个指标更长而可以获得更多的信息.
LINQ to SQL的发布时间比实体框架的发布时间长，但仅针对SQL Server的情况运行.它可以作为适合目标的ORM很好地工作，但是不像Entity Framework(提供eSql等)功能丰富.
LINQ to SQL非常容易掌握(取决于您对LINQ的了解)，最近，生成的查询的质量有所提高(自早期的beta开始).我不确定它的伸缩性或性能如何，但是您必须认为它与普通开发人员的手写T-SQL相当(好吧，这是一个疯狂的假设！).这非常简单，并且可以在Visual Studio中为您生成一个非常漂亮的模型.
对于非SQL Server数据库支持，还有其他(2)替代方法 >
实体框架是这三个中的最新版本，因此，仍有一些问题需要更正(希望在下一版本中).它可以与许多提供程序一起使用(不限于SQL Server)，并且具有其他优点，例如eSQL和(1)每种类型的表继承.刚开始学习时可能会有些棘手，但是一旦完成一两个解决方案，它就会变得可预测且易于实现.
由于它是最新的，因此在学习曲线上会花更多的钱(还有更多的东西要学习)，并且性能虽然不如目前理想(但是)，但是它确实提供了一些有趣的好处(尤其是对多个提供商的支持).
我想我的答复是-您是否正在评估，还是需要提供一个可行的(可用于生产的)ORM解决方案?
实体框架可能还没有准备好进行严肃的生产工作(较小的解决方案之外)，这使您只能使用LINQ to SQL或NHibernate.如果只打算使用SQL Server数据库，则LINQ to SQL是一个有趣的选择.否则，NHibernate可能是认真工作的最佳选择.
(1)[ http://msdn.microsoft.com/zh-我们/data/cc765425.aspx ] (2)[ http://www.devart.com/dotconnect/linq.html ]
I am looking for some guideline for my new application while choosing ORM. I want to evaluate EF over NHibernate and LINQ to SQL. I need some expert voice from this wonderful community. You can evaluate on following point.
- Scalability
- Learning curve
- Easy to use
- Performance ETC.
Well, of the three you've listed, NHibernate has been around the longest. If you want to work with something which has a proven track record, that's probably a safe place to begin.
It is pretty even across the four metrics (scale/learning curve/ease of use and performance) although you might find there is more information available due to it being around longer than the other two.
LINQ to SQL has been released longer than the Entity Framework, but only runs against SQL Server flavours. It works very well as a fit-for-purpose ORM, but is not a feature-rich as the Entity Framework (which provides eSql amongst other things).
LINQ to SQL is pretty easy to grasp (depending on your knowledge of LINQ) and more recently the quality of the generated queries has improved (since the earlier betas). I'm not sure how well it scales, or performs, but you'd have to think it's on par with an average developer's handwritten T-SQL (okay now that's a wild assumption!). It's pretty straightforward, and generates a very nice model for you within Visual Studio.
There are other (2) alternatives for non-SQL Server databases support
The Entity Framework is the newest of the three and as a result, still has some issues to be corrected (hopefully in the next version). It will work with a number of providers (it's not limited to SQL Server) and has additional goodness such as eSQL and (1) Table-Per-Type inheritance. It can be a bit tricky to learn at first, but once you've done one or two solutions with it, it gets predictable and easier to implement.
Due to it being the latest, it'll take a bit more in terms of learning curve (also there's more to learn), and the performance is.. less than desirable (at present) but it does offer some interesting benefits (especially the support for multiple providers).
I guess my question in reply is - are you just evaluating or do you need to produce a workable (production-ready) ORM solution?
The Entity Framework probably isn't quite ready for serious production work (outside of smaller solutions) which leaves you with LINQ to SQL or NHibernate. If you're only going to be working with SQL Server databases, LINQ to SQL is an interesting option. Otherwise, NHibernate is probably the best bet for serious work.
(1) [ http://msdn.microsoft.com/en-us/data/cc765425.aspx ] (2) [ http://www.devart.com/dotconnect/linq.html ]
这篇关于ADO.NET实体框架:ORM解决方案之间的决策的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
