Question

我正在开始一个新项目，我正在寻找一个非常好的ORM或非基于SQL的持久层。
对于这个项目，我真的不关心数据是如何持久化的，只要它能以合理的速度查询和存储，最重要的是简单的查询。应该无缝地处理并发（前端将在另一层上，并且将有几个同时用户，但不一定处理相同的数据）并且我必须更少关注数据层（简单查询，自动懒惰）装载等）更好我还想不惜一切代价避免使用基于字符串的查询，因此支持LINQ的工具或其他直观且可能强类型的查询会获得很大的好处。
最后使用POCO对象是我真正想做的另一件事这是我评估的产品列表以及它们不适合的原因，只是为了让我看不到任何关于使用它们的建议：

NHibernate：疯狂的xml，太多的设置，高维护复杂性和模型更改的成本，会话工厂很乱，不能很好地满足我的需求
Castle ActiveRecord：基于NHibernate，很少的文档以及与NHibernate相关的一些问题仍然适用。此外，为了得到合适的模型，它需要很多属性才能更好地手动创建模式，并且处理关系的方式是一种耻辱。
Linq To SQL：缺少POCO对象，根据MS，它不会提高加班时间（EF就是他们所承诺的）
实体Framweork：尽管在第4版中POCO对象是可能的，但它们仍然非常hacky并迫使你做太多的手工工作来设置。此外，v4只是一个测试版
LLBLGen Pro：很好，尤其是SelfServicing适配器，但不是POCO。此外，LINQ提供商还不完善。最后，删除一组对象是不可能通过LINQ导致混合API（其中一个远非直观）和我不喜欢。
XPO：除了直观，非常缓慢的并发问题，而不是POCO
SubSonic SimpleRepository：几分钟我以为我在做梦。当我弄清楚事情是如何处理关系时，deam结束了

我也查看了MongoDB和CouchDB，但在这些情况下，相关对象的捕获看起来像是在做正确的事情之前需要进行太多测试。此外，它们都不提供强类型查询。

提前感谢您的建议！

Answer 1

如果你能负担得起LLBLGen许可证，那就去吧。

我认真地不喜欢LINQ查询语法我使用它的次数越多（虽然我喜欢与扩展方法和表达式树相关的语言功能）。

我一开始喜欢和其他人一样，但不确定XYZ LINQ提供程序中的[[where employee.Name.StartsWith（“John Smit”）]]是在SQL语句中还是在LINQ to Objects中完成（在SQL返回所有结果），[[user.Roles.Contains（role）]]是否完全无效是一大步。

LLBLGen可以删除所有项目而不加载

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

这很简单，我喜欢它。您将获得延迟加载，并使用Prefetch API默认和/或按查询设置eager / deep加载。您可以动态（并轻松地）构建和构建任何无限级别的过滤器/排序/加载。非常好。

LLBLGen只有两个问题：第一，它的价格并非所有公司都愿意支付，特别是考虑到微软替代品的炒作。其次，命名约定虽然是RDBMS理论中的标准），比如PredicateFactory而不是“where”或“filter”和Prefetch而不是深度加载，甚至是SortExpression而不是orderby，对于第一个使用它的开发人员来说，这些都有点可怕时间，但很快你就会学会爱他们，因为他们给予了力量和轻松。在LLBLGen 3.0中有关于POCO支持的讨论。我无法分辨它，因为我不知道。

现在，鉴于我不再在使用LLBLGen的公司工作，该公司使用LINQ to SQL主要是因为它在许多项目中“经过验证”而没有出现大的故障（与EF 1不同，它在LINQ to SQL中缺乏LINQ功能）并且具有非常差的性能，并且在高级映射中可能非常有限 - 它应该是最好的！）。我在这家公司都使用过这两种产品并且都讨厌。新项目的决定仍然是LINQ to SQL，并尽我们所能来克服它的局限性。这个网站StackOVerflow本身就在它上面运行!!!您可以解决它来做SEMI-POCO（当谈到关联时，您仍然需要使用一些与L2S相关的类型。）

我也在家里做一些小项目。由于我不再拥有LLBLGen许可证，我决定学习NHibernate并将其与Fluent NHibernate和LINQ To NHibernate一起使用。我已经从中了解到NHibernate非常强大。它改变了我自动更新数据库模式等功能的工作方式（我几乎没有在使用它时触及D）。 LINQ提供程序（在NHibernate Contrib项目中）有时很缺乏，但是NHibernate的未发布的源代码本身包含一个更好的LINQ提供程序（还没有尝试过）。 NHibernate中的“Session”在进行类似于与L2S中的DataContext或EF中的ObjectContext相关的Web开发时会出现问题（LLBLGen不会因为自我跟踪实体而受到影响）。

我对NHibernate的最大问题是查找信息的能力。应该以某种方式放在一起并且没有太多指导的太多部分可以包括用于映射和查询的高级信息。如果不是我有一个朋友（Tuna Toksoz，@ tehlike在推特上）碰巧是NHibernate项目源代码的提交者，我真的遇到了麻烦。

我学到的道德是：如果你想要的东西只是工作而且有点基本使用Linq To Sql或SubSonic，如果你想要中间的东西，你的生产环境可以买得起BETA .NET版本（给定golive存在）使用实体框架4.0，如果你想要一个非常强大并且可以负担得起硬学习过程的东西去NHibernate，而且，最重要的是，如果你能买得起LLBLGen，那就用它了。

Answer 2

看看DataObjects.Net：

优点：

使用简单的类和属性轻松设计商业模式
数据库架构在运行时自动生成 - 因此您不必关心数据的持久性
自动延迟加载，透明持久性等...
非常好的LINQ实现
高性能

缺点：

不是POCO

Answer 3

尽管如此，我倾向于完全不同意你对NHibernate弱点的评估。

我认为XML映射非常简单直观。添加对NHibernate.dll的引用并创建SessionFactory也是件小事。维护和变更管理大大简化。会话工厂和会话非常容易理解和处理。

总体而言，我认为你的评估是情绪化的，而不是理性的。

Answer 4

您是否考虑过使用面向对象的数据库，例如db4o。虽然我从未使用过它，但是当我发现它时我发现它非常有趣：

它支持LINQ查询，使用POCO，如果我理解正确，数据只是存储在一个文件中（不需要安装数据库）。

部分链接：tutorial，forum post

Answer 5

LLBLGEN。

如果你认为你会找到一些可以打开所有盒子的东西，那么你可能会等待很长时间。

Answer 6

编写自己的ORM

听起来可能很疯狂，但你可以编写自己的ORM。有时回到项目中，客户不想使用第三方工具或库，因此我们最终编写了自己的ORM，为我们提供了特定的目标。您可以使用Attributes修饰对象的类和属性，以使用Database表和字段映射它们。拥有所有业务对象的基类，并使用反射对对象执行数据库操作。

通过这种方式，您可以构建自己的小型ORM以满足您想要的特定目标。供您参考它可能看起来像这样。

[TableMapping("Users", "User", "Users")]
public class User : EntityBase
{
    #region Constructor(s)
    public User()
    {
    }
    #endregion

    #region Properties

    #region Default Properties - Direct Field Mapping using DataFieldMappingAttribute

    private System.Int32 _UserId;

    private System.String _UserName;

    [DataFieldMapping("UserID")]
    [DataObjectFieldAttribute(true, true, false)]
    [NotNullOrEmpty(Message = "UserID Is Required.")]
    public override int Id
    {
        get
        {
            return _UserId;
        }
        set
        {
            _UserId = value;
        }
    }

    [DataFieldMapping("UserName")]
    [NotNullOrEmpty(Message = "Username Is Required.")]
    public string UserName
    {
        get
        {
            return _UserName;
        }
        set
        {
            _UserName = value;
        }
    }

    #endregion

    #region One-To-Many Mappings
    #endregion

    #region Derived Properties
    #endregion

    #endregion
}

Answer 7

我使用过LLBLGenPro，NHibernate和一些对象数据库。

我的第一个建议是NHibernate使用FluentNhibernate来处理映射。

我发现与使用NHibernate相关的90％的难度直接与XML映射相关联。当我切换FluentNhibernate时，痛苦就消失了。

另外10％的困难只是无知;我不明白。这不是NHibernate的错。

LLBLGenPro：我不知道Linq支持现在是什么样的，但在Linq得到支持之前，它是一个编写查询的PITA。我阅读了文档而且我得到了它，但是我的同事没有并且无休止地抱怨预取路径之类的复杂性。另外，就像你说的那样 - 不是POCO。加上成本，我认为这比它的价值更麻烦。

如果它不是客户端 - 服务器架构，我建议使用db40。我在一个小型私人项目中使用它并喜欢它。使用方便。伟大的小对象数据库。

Answer 8

看看EntitySpaces。我不能从我自己的亲身经历中推荐，但它对我的一位同事（不是他的...）非常有用。

Answer 9

看看Aspectize here

Answer 10

对我来说，答案已经证明是LLBLGen Pro。除了它的功能之外，您还获得了一个专门的支持团队，他们关心帮助您使项目正常工作，如果您发现了错误，在大多数情况下，您将在几小时或几天内得到修复。这无法最小化，因为它允许您继续工作而不是等待发布（几个月？）或自己修复错误。

Answer 11

您可以查看Telerik ORM。我没有在生产中使用它，但它基于一个名为POET的Java ORM \ ODB，几年前对我很有用。由于它使用了装配增强功能，因此与上面拒绝的某些产品相比，它提供了更加透明的体验。

就纯ODB而言FastObjects by Versant可能值得一看。

祝你好运 - 让我们知道你决定采用什么。

ORM /持久层建议

11 个答案: