在设计业务对象时,我尝试了几种不同的方法来编写数据访问层。有些人比其他人做得更好,但我一直觉得必须有一个“更好”的方法。
我真的很想看看人们在不同情况下处理 DAL 的不同方式,以及他们对该技术如何运作或运作不佳的看法。
在设计业务对象时,我尝试了几种不同的方法来编写数据访问层。有些人比其他人做得更好,但我一直觉得必须有一个“更好”的方法。
我真的很想看看人们在不同情况下处理 DAL 的不同方式,以及他们对该技术如何运作或运作不佳的看法。
我现在非常依赖Billy McCafferty 的 NHibernate 最佳实践文章/许多 Web/WinForms 应用程序的示例代码。这是一篇写得很精彩的文章,除了教您基本的 NHibernate 和 TDD 之外,它还将为您提供一个很好的可靠示例架构。他试图向您概述他的架构和设计决策。
他使用通用 DataAccessObjects 创建了一个非常优雅的 DAL,您可以为每个域对象扩展它——并且它使用接口和 DAOFactory 非常松散地耦合到 BL。我建议首先查看 BasicSample,特别是如果您以前没有使用过 NHibernate。
请注意,本文严重依赖 NHibernate,但我认为可以轻松更改它的通用方法以适应其他 ORM。
不幸的是,我认为没有“更好的方法”,它过于依赖于您使用的 DAL 方法的具体情况。Martin Fowler的企业应用程序架构模式是对“最先进技术”的一个很好的讨论。
第 10 章,数据源架构模式专门讨论了业务应用程序中最常用的模式。
但总的来说,我发现使用满足基本可维护性和适应性要求的最简单方法是最佳选择。
例如,在最近的一个项目中,我只需要一个简单的“行数据网关”。(这只是为每个相关数据库表生成的代码类,包括执行 CRUD 操作的方法)。没有关于 ORM 与存储过程的无休止的争论,它只是工作,并且很好地完成了所需的工作。
如果您要走 NHibernate 路线(上面@Watson 的好文章链接顺便说一句),那么我强烈建议您从 codebetter 签出 suvius-flamingo 示例项目。他有一个非常漂亮、简洁的示例项目,展示了 MVC 和 NHibernate 的实际应用。
[更新]这不再有效,这个项目的设计被改变了[/更新]
在我们的开源项目 Bunian 中,我们得出结论,业务对象(整个组件)是系统的核心,一切都应该围绕它,包括数据访问层。
业务组件将向其他人指示它需要什么,通过 itnerfaces 暗示这一点。例如 Business Object Person将有一个名为IRepositoryForPerson的接口成员,该成员将在需要时通过依赖注入容器分配一个实例。
有关更多详细信息,请在此处查看我的博客文章:
http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//
并在这里查看 Bunian 的代码(虽然它还很业余):
http://www.codeplex.com/Bunian
当然,这种方法会出现新事物,例如数据访问会话的生命周期(例如,如果您使用 NHibernate)。但那是我想的另一个问题:)
希望这个对你有帮助
我假设您的意思是编写访问 SQL 的 DAL,因为这是当今最常见的部分。如果针对 SQL 编写 DAL 的最大问题是 ORM 部分。也就是说,OO 编程和关系数据库模式之间存在根本的阻抗不匹配。在编写 ORM 方面已经有许多伟大的、甚至是成功的尝试。但是它们都面临着同样的问题,而这正是它们的好处:它们将您从正在生成的底层 SQL 中抽象出来。为什么这是一个问题,因为您的数据库的性能是您的系统整体运行情况的关键组成部分。许多 ORM(也许是大多数)不仅在许多标准查询中表现不佳,但实际上鼓励使用会大大降低性能的模式(查询集合时在循环内重复遍历关系是一个常见的例子,解决死锁是另一个例子)。当然,在详细学习了 ORM API 之后,通常可以找到绕过这些性能坑洞的方法。
我目前对 ORM 状态的看法是,我希望它做的事情尽可能少,同时仍然为我提供一个可靠的库的效率,该库负责处理数据访问的所有细节。换句话说,因为我认为它们还不够“好”,并且可能永远不会使用 SQL 作为后端,所以我想保留在裸机级别的控制权,我将通过以下方式开始编写 SQL在许多情况下,无论 ORM 是什么,都会毫不犹豫地动手,因为我知道我希望根据给定需求查询数据的具体方式。
这显然是一种比您虔诚地按照预期使用 ORM 更脆弱的编码方法,因此,您必须在单元测试、SQL 注入和适当的关注点分离方面更加勤奋。所以,总而言之,我同意 Ash,虽然这并不意味着他/她同意我 :)