业务对象DAL设计

Question

在设计业务对象时，我尝试了几种不同的写入数据访问层的方法。有些人比其他人做得更好，但我一直觉得必须有一个“更好”的方式。

我真的只想看看人们在不同情况下处理DAL的不同方式，以及他们对该技术如何运作或运作不良的看法。

Answer 1

我现在非常依赖Billy McCafferty's NHibernate Best Practices article / sample code来处理许多Web / WinForms应用程序。这是一篇精彩的文章，将为您提供良好的实体样本架构 - 除了教您基本的NHibernate和TDD。他试图向您概述他的架构和设计决策。

他使用通用DataAccessObjects创建了一个非常优雅的DAL，您可以为每个域对象扩展它 - 并且它使用接口和DAOFactory非常松散地耦合到BL。我建议首先查看BasicSample，特别是如果你之前没有使用过NHibernate。

请注意，这篇文章在很大程度上依赖于NHibernate，但我认为它可以很容易地改变以适应其他ORM。

Answer 2

不幸的是，我认为没有“更好的方法”，它过于依赖于您使用DAL方法的具体情况。 马丁福勒对{“3}}的”最新技术“进行了很好的讨论。

第10章，数据源架构模式专门讨论了大多数最常用的业务应用程序模式。

总的来说，我发现使用最简单的方法来满足基本的可维护性和适应性要求是最好的选择。

例如，在最近的项目中，我只需要一个简单的“行数据网关”。 （这只是每个相关数据库表的代码生成类，包括执行CRUD操作的方法）。没有关于ORM与存储过程的无休止的争论，它只是起作用，并且做得很好。

Answer 3

有几种常见的模式。 'The patterns of enterprise architecture'本书是这方面的一个很好的参考：

• 表数据网关
• 行数据网关
• Active Record
• 数据映射器

如果您使用ORM，例如llblgen，您可以选择自助服务或适配器。

Answer 4

如果您正在沿着NHibernate路线走下去（上面的@Watson链接BTW的好文章），那么我强烈建议您从codebetter查看suvius-flamingo示例项目。他有一个非常好的，简洁的示例项目，它展示了MVC和NHibernate。

这是suvius-flamingo link。

Answer 5

[更新]这已不再有效，此项目的设计已更改[/ update]

在我们的开源项目Bunian中，我们得出结论，Business Objects（整个组件）是系统的核心，一切都应围绕它，包括数据访问层。

业务组件将向其他人指示它需要什么，这意味着通过itnerfaces。例如，Business Object Person 将有一个名为 IRepositoryForPerson 的接口成员，该成员将在需要时通过Dependency Injection容器分配一个实例。

有关详细信息，请查看我的博客文章：

http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//

并在这里查看Bunian的代码（尽管它还是业余的）：

http://www.codeplex.com/Bunian

当然，这种方法会出现新的事物，例如数据访问会话的生命周期（例如，如果你使用的是NHibernate）。但那是我猜的另一个问题：）

我希望你找到这个有用的

Answer 6

我将假设你的意思是编写一个访问SQL的DAL，因为这是今天最常见的部分。如果针对SQL编写DAL的最大问题是ORM部分。也就是说，OO编程和关系数据库模式之间存在基本的阻抗不匹配。在编写ORM时，已经有许多伟大的，成功的尝试。但是他们都受到同样的问题的困扰：他们将你从正在生成的底层SQL中抽象出来。为什么这是一个问题，数据库的性能是整个系统功能的关键组成部分。许多ORM（可能是大多数）不仅在许多标准查询中具有不太出色的性能，而且实际上鼓励使用的模式会大大降低性能（在查询集合时，在循环内反复遍历关系是一个常见的例子，使解决死锁变得困难）另一个）。当然，在详细了解ORM API之后，您通常可以找到解决这些性能问题的方法。

我目前对ORM状态的看法是，我希望它尽可能少地做，同时仍然给我一个实体库的效率，它可以处理所有数据访问的细节。换句话说，因为我认为它们还没有“足够好”，并且可能永远不会以SQL作为后端，所以我希望在裸机级别保留控制权，并且我将继续编写SQL在很多情况下，无论ORM如何，我都毫不犹豫地交手，因为我知道我希望根据我的特定需求查询数据的具体方式。

这显然是一种更脆弱的编码方法，而不是像你原来那样虔诚地使用ORM，因此，你必须在单元测试，SQL注入和关注点的正确分离方面做得更加勤奋。所以，总而言之，我同意Ash，虽然这并不意味着他/她同意我：）