26

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

  • NHibernate：疯狂的 xml 东西，设置太多，维护复杂性高，模型更改成本高，会话工厂很乱，不适合我的需求
  • Castle ActiveRecord：基于 NHibernate，很少的文档加上一些与 NHibernate 相关的问题仍然适用。此外，为了获得体面的模型，它需要这么多属性，以致于手动创建模式会更好，而处理关系的方式是一种耻辱。
  • Linq To SQL：缺少 POCO 对象，根据 MS 的说法，加班时间不会有太大改善（EF 是他们所承诺的）
  • Entity Framweork：虽然在 v4 中 POCO 对象是可能的，但它们仍然非常老套，并迫使您做太多的手动工作来进行设置。此外，v4 只是一个测试版
  • LLBLGen Pro：很好，尤其是使用 SelfServicing 适配器，但不是 POCO。此外，LINQ 提供程序还不完美。最后，通过 LINQ 删除一组对象是不可能的，这会导致混合 API（其中一个很不直观）并且我不喜欢。
  • XPO：除了直观、非常慢、并发问题之外的任何东西，而不是 POCO
  • SubSonic SimpleRepository：有几分钟我以为我在做梦。当我弄清楚这件事如何处理人际关系时，这个项目就结束了

我还研究了 MongoDB 和 CouchDB，但在这些情况下，相关对象的捕获看起来需要进行太多测试才能正确处理。此外，它们都不提供强类型查询。

提前感谢您的建议！

4

11 回答 11

7

如果你能负担得起 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 设置急切/深度加载。您可以动态（轻松地）组合和构建无限级别的任何过滤器/排序/加载。这是很不错的。

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 提供程序（尚未尝试过）。当您进行类似于 L2S 中的 DataContext 或 EF 中的 ObjectContext 的 Web 开发时，NHibernate 中的“会话”会出现问题（由于自我跟踪实体，LLBLGen 不会受到这些问题的影响）。

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

我学到的道理是：如果你想要一些可以工作的东西并且有点基本使用 Linq To Sql 或 SubSonic，如果你想要中间的东西并且你的生产环境可以负担 BETA .NET 版本（假设 golive 存在）使用 Entity Framework 4.0 ，如果你想要一些非常强大的东西，并且可以负担得起艰苦的学习过程，那就去 NHibernate，而且，最好的是，如果你负担得起 LLBLGen，就使用它。

于 2009-10-31T13:49:45.800 回答
6

看看DataObjects.Net：

优点：

  • 使用简单的类和属性轻松设计业务模型
  • 数据库模式是在运行时自动生成的——所以你不必关心数据是如何被持久化的
  • 自动延迟加载、透明持久化等...
  • 非常好的 LINQ 实现
  • 高性能

缺点：

  • 不是 POCO
于 2009-11-02T08:16:38.120 回答
4

恕我直言，我倾向于绝对不同意您对 NHibernate 弱点的评估。

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

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

于 2009-10-31T15:28:11.740 回答
3

您是否考虑过使用面向对象的数据库，例如db4o。虽然没用过，但是发现的时候觉得挺有意思的：

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

一些链接：教程，论坛帖子

于 2009-10-31T12:27:01.550 回答
2

编写自己的 ORM

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

通过这种方式，您可以构建自己的微型 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
}
于 2009-11-02T08:34:31.797 回答
2

LLBLGen。

如果你认为你会找到符合你所有条件的东西，那么你可能会等待很长时间。

于 2009-10-31T15:03:51.197 回答
2

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

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

我发现与使用 NHibernate 相关的 90% 的困难与 XML 映射直接相关。当我切换 FluentNhibernate 时，疼痛消失了。

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

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

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

于 2009-11-30T22:46:05.057 回答
1

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

于 2009-11-01T12:40:02.297 回答
1

看看EntitySpaces。我不能从我自己的个人经验中推荐，但它对我的一位同事（他不喜欢软...）很有效

于 2009-10-31T15:14:15.077 回答
1

在此处查看 Aspectize

于 2009-10-31T20:18:40.023 回答
1

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

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

祝你好运 - 让我们知道你决定选择什么。

于 2009-11-26T00:19:37.770 回答