ORM /持久层的建议 [英] ORM/Persistence layer Advice

问题描述

大家好
我开始一个新的项目，我环顾四周为任何一个很好的ORM或用于非基于SQL的持久层。
对于这个项目，我真的不关心的数据是如何坚持，只要它可以查询和存储的一个合理的速度，用简单的查询最重要的。
并发应无缝处理（前端将在另一层及以后还有几个用户同时使用，但不一定工作在相同的数据），我越要集中在数据层上（容易查询，自动懒负载等）就更好了。
我也想不惜一切代价避免弄乱基于字符串的查询，以便工具支持LINQ或以其他方式直观和可能强类型的查询得到一个巨大的奖赏。
最后，在与POCO的对象是另一回事我真的想这样做
以下是产品的清单，我评估，为什么他们不适合，只是让我不明白如何使用那些任何意见：

Hi all
I'm starting a new project and I'm looking around for either a very good ORM or for a non-SQL-based persistence layer.
For this project, I really don't care on how the data is persisted, as long as it can be queried and stored with a reasonable speed and most importantly with simple queries.
Concurrency should be handled seamlessly (the front-end will be on another tier and there'll be several simultaneous users, although not necessarily working on the same data) and the less I have to focus on the data layer (easy queries, automatic lazy loading etc) the better.
I also want to avoid at all cost having to mess with string-based queries so tools supporting LINQ or otherwise intuitive and possibly strongly typed queries get a big bonus.
Finally working with POCO objects is another thing I'd really want to do
Here's a list of products I've evaluated and why they don't fit, just so that I don't see any advice about using those:

• NHibernate的：疯狂的XML的东西，太多的设置，高维护的复杂性和成本模式的转变，会话工厂是混乱和不与我的需求合身
• 城堡的ActiveRecord：NHibernate的基础，小文件以及与NHibernate的仍然适用的一些问题。此外，为了得到体面的车型需要这么多的属性，一个是最好手动创建模式，以及关系的处理方式是一种耻辱。
• 的LINQ to SQL：缺少POCO的对象，并根据MS也不会提高多少加班费（EF是他们正在致力于）
• 实体Framweork：虽然在V4 POCO对象是可能的，他们仍然pretty的哈克，并强迫你做太多的体力工作设置的东西了。此外，V4仅仅是一个测试版
• LLBLGEN临：好，特别是与SelfServicing适配器，而不是POCO。此外，LINQ提供程序还不完善。最后，通过LINQ导致混合的API（其中一个是远远的直观），而且我不喜欢删除一组对象是不可能的。
• XPO：什么，但直观的，速度很慢，并发问题，而不是POCO
• 亚音速SimpleRepository：几分钟后，我想我是在做梦。该妇女警察走到了尽头，因为我想通了是怎么回事没处理好人际关系

我也看了的MongoDB和CouchDB的，但在这种情况下与相关对象的渔获量看起来他们需要得到正确的事情之前，太多的测试。除了他们没有提供强类型的查询。

在此先感谢您的建议！

I've also looked at MongoDB and CouchDB but in those cases the catches with related objects looked like they required too much testing before getting things right. Besides none of them offers strongly typed queries.

Thanks in advance for your suggestions!

推荐答案

如果你能负担得起LLBLGEN许可证，去了。

If you can afford LLBLGen license, go for it.

我严重不喜欢LINQ查询语法我越使用它（虽然我爱与之相关的像扩展方法和Ex pression树木的语言功能）。

I seriously don't like LINQ query-syntax the more I work with it (although I LOVE the language features related to it like Extension Methods and Expression Trees).

我喜欢在第一次和其他人一样，但作为尚不能确定是否[其中，employee.Name.StartsWith（约翰斯密特）]在XYZ LINQ提供程序将在SQL语句或LINQ做对象（后SQL返回的结果），以及是否[user.Roles.Contains（角色）]将在所有的工作与否的一大步落后。

I loved at first like everybody else, but being uncertain whether [[ where employee.Name.StartsWith("John Smit") ]] in that XYZ LINQ provider will be done in SQL statement or in LINQ to Objects (after the SQL returns all results), and whether [[ user.Roles.Contains(role) ]] will at all work or not is a big step behind.

LLBLGEN可以删除所有项目不加载这些容易，因为

LLBLGen can make deleting all items without loading them as easy as

MyEntityCollection.DeleteAll( new MyEntity {Condition = value} );

这是pretty的简单，我喜欢它。你变懒加载和设置急切/深加载默认和/或每使用prefetch API查询。您可以在无限的水平撰写和动态（轻松）建造任何过滤器/排序/加载。这是非常好的。

This is pretty simple and I like it. You get lazy loading and you set eager/deep loading by default and/or per query using Prefetch API. You can compose and construct dynamically (and easily) any filter/sort/loading at infinite levels. It's very nice.

有只有两个约LLBLGEN问题：第一，它的价格不是所有的公司愿意支付特别是考虑到炒作微软的替代品有。其次，虽然在关系型数据库理论标准），如predicateFactory，而不是里或过滤器和prefetch，而不是深装，甚至SORTEX pression代替排序依据的命名规则，这些都是一点点可怕的开发人员正在使用它的第一次，但很快你要学会爱他们，赋予的权力，缓解他们给。大约有POCO支持LLBLGEN 3.0会谈。我不能告诉它，因为我不知道。

There are only two problems about LLBLGen: first, it's price not all companies would love to pay especially given the hype Microsoft alternatives have. Second, the naming convention although standard in RDBMS theories) like PredicateFactory instead of "where" or "filter" and Prefetch instead of deep loading and even SortExpression instead of orderby, those all are a little scary to a developer working with it for the first times, but soon you learn to love them, given the power and ease they give. There are talks about POCO support in LLBLGen 3.0. I cannot tell about it because I don't know.

现在给予我不再工作，在使用LLBLGEN一家公司，该公司使用LINQ to SQL主要是因为它是在这么多的项目没有大的失误证明（不同于EF 1，这是缺乏在LINQ甚至LINQ功能，SQL并具有非常不好的性能，可以说是相当限制高级映射！ - 它应该是最适合）。我在这家公司同时使用和恨恶了。新项目的决定仍LINQ to SQL的，并竭尽所能去克服它的局限性。本网站StackOverflow的本身在它上面运行的！你可以解决它做半POCO（你仍然需要使用相关类型的一些L2S当谈到协会）。

Now given I no longer work in a company that uses LLBLGen, the company uses LINQ to SQL mainly because it's "proven" in so many projects without big failures (unlike EF 1, which is lacking even LINQ features in LINQ to SQL and has very bad performance and can be quite limiting in advanced mapping - which it should be best for!). I used both in this company and hated both. The decision for new projects remained LINQ to SQL, and doing all we can to overcome it's limitations. This website StackOVerflow itself runs on top of it!!! You can work around it to do SEMI-POCO (you still need to use some L2S related types when it comes to associations).

我也是在家里做一些小项目。因为我不再有LLBLGEN执照，我决定学习NHibernate和使用它和连贯NHibernate和LINQ to NHibernate的。我已经通过这个了解到，NHibernate的是非常强的。它改变了我是如何工作的一些功能，如自动更新数据库架构（在使用它，我从来不碰为D差不多）。 LINQ提供程序（在NHibernate的的Contrib项目）相当，有时缺乏，但有NHibernate的的未发行的源$ C ​​$ C本身包含了一个更好的LINQ提供程序（还没有尝试过呢）。在NHibernate的会话有问题，当你正在做类似在EF与DataContext的在L2S或ObjectContext的（LLBLGEN不会从那些得益于自我跟踪实体吃亏）。

I also do some small projects at home. Since I no longer have LLBLGen license, I decided to learn NHibernate and use it along with Fluent NHibernate and LINQ To NHibernate. I have learned through this that NHibernate is VERY strong. It changed how I work by some features like updating DB schema automatically (I never touched the D almost when using it). LINQ provider (in NHibernate Contrib project) is quite lacking sometimes but there is the unreleased source code of NHibernate itself contains a better LINQ provider (haven't tried it yet). The "Session" in NHibernate has problems when you are doing web development similar to those related to DataContext in L2S or ObjectContext in EF (LLBLGen doesn't suffer from those thanks to self tracking entities).

最大的问题，我与NHibernate的虽然是能否找到信息。太多的作品，应放在一起，在某种方式上并没有太大的指导可以包括两个映射和查询先进的信息。如果不是我有一个朋友（金枪鱼Toksoz，@tehlike在twitter）谁发生在NHibernate的项目源$ C ​​$ C提交者，我真的有很大的麻烦。

The biggest problems I had with NHibernate though was ability to find information. Too many pieces that should be put together in certain way and not much guidance can include advanced information for both mapping and querying. If not I had a friend (Tuna Toksoz , @tehlike on twitter) who happened to be a committer in NHibernate project source code, I'd really be in serious trouble.

我学到的道德是：如果你想要的东西，只是工作，还有一点基本的使用LINQ to SQL或亚音速，如果你想要的东西在中间和生产环境可以承受BETA .NET版本（给定的GoLive存在）使用实体框架4.0，如果你想要的东西非常强大，可以承受的艰苦学习过程中去NHibernate的，和，最佳所有，如果你能负担得起LLBLGEN，使用它。

The moral I learned was: If you want something that just works and a bit basic use Linq To Sql or SubSonic, if you want something in the middle and your production environment can afford BETA .NET version (given golive exists) use Entity Framework 4.0, if you want something very powerful and can afford the hard learning process go to NHibernate, AND, BEST OF ALL, if you can afford LLBLGen, USE IT.

这篇关于ORM /持久层的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！