从领域模型到事务脚本

Question

我开始的新地方刚刚开始从头开始开发一个全新的产品。他们在应用程序服务中使用事务脚本，完全愚蠢的实体，以及带有存储过程的手动 DAL（论点是 nhibernate 不能很好地优化 sql，加载太多东西，不能很好地扩展到大型项目等等等等）。该应用程序应该是刚刚起步的巨大项目。

我来自一个从事领域模型的职位，所有业务逻辑都封装在其中，而应用服务仅处理基础架构 + 使用 nhibernate 加载模型并编写脚本。

我真的相信采用第二种方法要好得多。我正计划做一个关于为什么的演讲。我有很多书籍/文章/个人意见可以支持这一点......但作为一个“初级”可能意义不大（我也是我最后一个地方的单身开发者）。

我正在寻找更多资深人士的一些经验/提示/失败项目示例，为什么使用事务脚本/手动 DAL 不是正确的想法。

Answer 1

除了Paul T Davies 和Magnus Backeus 所说的。我认为最终这将是一个人和文化问题。如果人们思想开放并且愿意学习，那么说服他们相对容易。如果他们认为您是“初级”（这是一个不好的迹象，因为唯一重要的是您所说的而不是您的年龄/经验），您可以向“更高的权威”申诉：

• Patterns of Enterprise Application Architecture
• Domain-Driven Design
• Growing Object Oriented Software
• Dependency Injection in .NET

存储过程已经死了，你不是only one who thinks so：

令我们吃惊的是，我们在 2011 年继续寻找新系统 在存储过程中实现重要的业务逻辑。 常用于实现存储过程的编程语言 缺乏表现力，难以测试，不鼓励清洁 模块化设计。您应该只考虑执行存储过程 在特殊情况下，在数据库引擎内，如果有 是一个经过验证的性能问题。

说服不愿意改进和学习的人是没有意义的。例如，即使您设法赢得了一场争论并挤进了 NHibernate，他们最终也可能会像以前那样编写相同的紧密耦合、不可测试、面向数据或 linq 的代码。 DDD 很难，它需要改变很多假设，伤害自尊心等。根据公司的规模，这可能是一场不值得开始的持续战斗。

Driving Technical Change 这本书可能会帮助您处理这些问题。它包括您可能会遇到的几种行为刻板印象：

• 不知情的人
• 牛群
• 愤世嫉俗的人
• 被烧毁的人
• 时间紧迫
• 老大
• 非理性

祝你好运！

Answer 2

嗯，硬币总是有两面的。 他们可能对 Nhibernate 和性能问题有一些看法。但总有解决方案，比如加载策略，您可以准确地告诉 Nhibernate 应该如何处理特定的关键查询。 通过加载策略、缓存和 sql 索引调优，您可以在性能方面取得很大进展，真的很远。 但 ORM 的真正好处在于它减少了代码库并使其更加 DRY。使您的系统更易于维护。它还减少了“层”，因为您不需要存储过程。

我参与过几个像你这样的项目，相信我，他们面临着维护问题 * 应用程序服务中可能存在冗余代码，因为您没有可以将逻辑放在一个地方而不是出现在多个应用程序服务方法中的域核心。

• 包含多个存储过程的巨大 DAL 层。

• 逻辑很容易滑出到 GUI

我可以将列表加长...但我的观点是人们倾向于选择 Transaction 脚本有时只是因为它易于理解、易于上手并且性能良好。 但通常问题发生在顾问、员工离开项目和维护团队接管时。通常不清楚应该在哪里进行更改，而且我见过的大多数 TS 应用程序都被架构滥用了。它们从一开始就是很好的应用程序，但自从邀请您将逻辑放入 SP、服务、GUI 中（因为缺乏受限的 API、接口等）。

你跟着我？ /马格纳斯

p.s 您可以通过 CQRS 方法获得出色的性能和 DDD...

Answer 3

我会说拿材料来支持它是要走的路，这样他们就不能用你的经验不足作为论据（尽管在我看来你不是特别缺乏经验或初级！）。我的主要推荐是这本书：

http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X/ref=sr_1_1?ie=UTF8&qid=1317121019&sr=8-1

在第 146 页，它指出：

'TS 适用于业务逻辑简单明了的简单场景，更好的是，不太可能改变和发展。'

这并不描述您正在使用的系统。

然后继续描述域模型，以及为什么它适合更大的系统。

我会质疑他们是否理解他们选择的是事务脚本？以我的经验，TS 通常是没有经验的组织的默认选择，他们甚至不了解甚至有一个选项。他们只是认为'这就是它的完成方式'。他们当前的代码有多成功和可维护性如何？如果他们为大型项目选择 TS，我的猜测是“不太”！当出现问题时，他们会责怪客户更改规格吗？如果是这样，这表明他们对架构的选择是错误的。

根据我的经验，实现领域模型的开销很小。而且这比尝试扩展和维护架构不佳的系统要痛苦得多。

此外，在当今时代，数据库服务器应该能够毫无问题地处理基于 NHibernate 的系统。如果不能，那就是数据库服务器的问题。他们打算如何对这些存储过程进行单元测试？我通常发现 SP 是开发人员错误的最大点。

就像 Magnus 说的，我可以继续讨论这个问题。我不知道系统的细节，但是一旦你使用了HUGE这个词，领域模型就成为最明显的选择。