代码之家 › 专栏 › 技术社区 › Albert

持久性框架?

persistence linq-to-entities ado.net nhibernate linq

Albert · 技术社区 · 16 年前

我正试图决定访问数据库的最佳策略。我知道这是一个一般性的问题,没有一个好的答案,但是我会提供一些关于我正在寻找什么的指导方针。在过去的几年里,我们一直在使用我们自己的持久性框架,尽管有限的框架也起到了同样的作用。然而,它需要一些主要的改进,我想知道我应该这样做还是使用现有的框架之一。我要寻找的标准,按重要性顺序是:

客户端代码应该使用干净的对象,宽度没有数据库知识。当使用我们的自定义框架时,客户机代码看起来像:

sessionManager session=new sessionManager(); order order=session.createEntity(); order.date=datetime.now; //设置其他属性 orderDetail detail=order.addorderDetail(); detail.product=产品; //其他属性

//立即提交所有更改 session.commit();
应该尽量简单,不要“太灵活”。我们需要一种单一的方式来做大多数事情。
应该对面向对象编程有很好的支持。应该处理一对多和多对多的关系,应该处理继承,支持懒惰加载。
配置最好是基于XML的。

根据我目前的知识,我看到了以下选项:

改进我们当前的框架——问题是它需要大量的努力。
ADO.NET实体框架-没有很好的理解,但看起来太复杂,评论也不好。
linq-to-sql-对面向对象的实践没有很好的处理。
NHibernate-似乎是一个不错的选择,但有些用户报告了太多的古老错误。
亚音速-从一个简短的介绍来看,它似乎太灵活了。我不想那样。

你有什么建议?

编辑:

感谢克雷格的详细回答。我认为如果我提供更多关于我们的定制框架的细节,它将有更多的帮助。我在找类似的东西。这就是我们的定制框架的工作原理:

它是基于数据集的,所以您首先要做的是配置数据集和编写您需要的查询。
创建一个XML配置文件,指定数据集表如何映射到对象,并指定它们之间的关联(支持所有类型的关联)。 3.自定义工具解析XML配置并生成必要的代码。 4.生成的类继承自公共基类。

为了与我们的框架兼容,数据库必须满足以下标准:

每个表都应该有一列作为主键。
所有表都必须具有在上生成的相同数据类型的主键。客户端。
要处理继承,只支持单表继承。还有XML文件,几乎总是提供一种实现某种东西的方法。

我们现在要支持的是:

从数据集中删除依赖项。应自动生成SQL代码,但框架不应生成架构。我想手动控制DB模式。
更强大的继承层次结构支持。
与LINQ的可选集成。

我希望现在我要找的更清楚了。

5 回复 | 直到 7 年前

Craig Stuntz 16 年前

改进我们当前的框架-问题是它需要大量的努力

在您的问题中,您没有给出一个理由,为什么您应该重写从许多其他地方提供的功能。我建议,改造一个ORM并不能很好地利用你的时间,除非你对ORM有独特的需求,而你在你的问题中没有具体说明。

ADO.NET实体框架

我们在现实世界中使用实体框架,即生产软件。复杂的?据我所知,不比大多数其他的恐怖分子多, 也就是说,“相当复杂。” 然而,它是相对较新的,因此社区经验和文档比类似NHibernate的东西少。因此,缺少文档可能会使其看起来更加复杂。

实体框架和nHibernate对对象关系划分的桥接问题采取了截然不同的方法。关于这一点,我已经在 this blog post . 你应该考虑哪种方法对你最有意义。

关于实体框架,有很多评论,既有正面的,也有负面的。其中有些是有根据的,有些似乎来自于推动其他解决方案的人。有根据的批评包括

缺少POCO支持。这对某些应用程序来说不是问题,对其他应用程序来说是问题。Poco支持可能会在未来的版本中增加,但是今天,实体框架所能提供的最好的支持是IPOCO。
单片映射文件。这对我们来说并不是一个大问题,因为我们的元数据并不是不断变化的。

然而,在我看来,有些批评似乎是对森林的树木怀念。也就是说,他们谈论的功能不是对象关系映射的基本功能,实体框架已经证明了这一点。

linq to sql-对面向对象的实践没有很好的处理能力

我同意。我也不喜欢SQL Server焦点。

NHibernate-似乎是一个不错的选择,但有些用户报告了太多的古老错误。

好吧,NHibernate的好处在于它周围有一个非常活跃的社区,当你遇到这些深奥的错误时(相信我,实体框架也有它的深奥的错误;它似乎与领域一起出现),你可以很容易地找到解决方案。也就是说,我在NHibernate没有太多的个人经验,超出了我们选择实体框架的评估,所以我将让其他有更直接经验的人对此发表评论。

亚音速-从一个简短的介绍来看,它似乎太灵活了。我不想那样。

当然,亚音速不仅仅是一个ORM,而且亚音速用户可以选择选择不同的ORM实现,而不是使用亚音速的ActiveRecord。作为一个Web应用程序框架,我会考虑它。然而,它的ORM特性并不是它的起源D'195; tre,我认为有理由怀疑亚音速的ORM部分会比专用的ORM框架得到更少的关注。

Matt 16 年前

LLBLGen 做一个很好的ORM工具,它可以满足你的所有需求。

Simon 16 年前

iBATIS 是我最喜欢的,因为您可以更好地控制SQL

David Grayson 16 年前

Developer Express持久性对象或 XPO 众所周知。我用了3年。它提供了您所需要的一切,除了它是商业性的,并且您将自己与另一家(单个公司)捆绑在一起进行开发。除此之外,DeveloperExpress是.NET平台的最佳组件和框架提供程序之一。

xpo代码的一个例子是:

using (UnitOfWork uow = new UnitOfWork())
{
  Order order = new Order(uow);
  order.Date = DateTime.Now();
  uow.CommitChanges();
}

s3v1 16 年前

我建议你看看 ActiveRecord from Castle 我没有这方面的生产经验,我只是在玩他们的应用程序示例。工作起来似乎很容易,但我不太清楚它是否符合你的要求。