我刚开始的新地方刚刚开始从零开始开发一种全新的产品。他们在应用程序服务中使用事务脚本，完全愚蠢的实体，并且用存储过程手动滚动DAL（参数是nhibernate不能很好地优化sql，加载太多东西，不能很好地扩展到大型项目等等等）。该应用程序应该是处于婴儿期的巨大项目。
我来自一个我正在做域模型的位置，其中所有业务逻辑都封装在其中，而app服务只处理基础架构+使用nhibernate加载模型并编写脚本。
我真的相信第二种方法更好。我打算做一个关于原因的演讲。我有很多书籍/文章/个人意见，我可以用它来支持......但是在那里更多的是“初级”它可能没什么意义（我也是我最后一个地方的单一开发者）。
我正在寻找的是一些来自更高级别人员的失败项目的经验/提示/示例，为什么要进行交易脚本/手动滚动DAL不是正确的想法。
答案 0 :(得分：1)
总有两面硬币。 他们可能对Nhibernate和性能问题有一些看法。但总有解决方案，比如加载策略，你可以准确地告诉Nhibernate应该如何处理特定的批评查询。 使用加载策略，缓存和sql索引调优，你可以在很远的情况下获得性能。 但ORM的真正好处在于它减少了代码库并使其更加干燥。使您的系统更易于维护。它还减少了“层”，因为您不需要存储过程。
我参加过像你这样的几个项目，并相信我，他们面临着主要的问题 *可能是应用程序服务中的冗余代码，因为您没有可以将逻辑放在一个地方而不是出现在多个应用程序服务方法中的域核心。
包含多个存储过程的巨大DAL层。
逻辑容易滑入GUI
我可以让列表更长......但我的观点是人们倾向于选择事务脚本有时只是因为它易于理解，从一开始就可以擅长性能。 但是，当顾问，员工离开项目和维护团队接管时，通常会出现问题。通常没有cristal明确应该进行哪些更改，并且我看到的大多数TS应用程序都被架构滥用。它们从一开始就是很好的应用程序，但是因为邀请你把逻辑放在SP，服务，GUI中（因为缺乏受限制的API，接口等）。
你跟着我吗？ /马格努斯p.s使用CQRS方法可以获得出色的性能和DDD ......
答案 1 :(得分：1)
我会说采取材料支持它是要走的路，这样他们就不能用你的经验作为一个论点（虽然听起来你并不是特别缺乏经验或初中！）。我的主要推荐是这本书：
在第146页，它说明：
'TS适用于业务逻辑简单，更好，不太可能改变和发展的简单场景。'
这并未描述您正在使用的系统。
然后继续描述域模型，以及它适用于更大系统的原因。
我会质疑他们是否明白这是他们选择的交易脚本？根据我的经验，TS通常可以成为没有经验的组织的默认选择，他们甚至不了解甚至有一个选项。他们只是想'这是怎么做的'。他们目前的代码有多成功和可维护？如果他们为大型项目选择TS，我的猜测是“不是很好”！当出现问题时，他们是否责怪客户改变规格？如果是这样，这表明他们选择的架构是错误的。
根据我的经验，实施域模型的开销很小。与试图扩展和维护架构严密的系统相比，它要轻松得多。
此外，在这个时代，数据库服务器应该能够处理基于NHibernate的系统而没有任何问题。如果不能，则这是数据库服务器的问题。他们如何打算对这些存储过程进行单元测试？我经常发现SP是开发人员错误的最大点。
像马格努斯说的那样，我可以继续谈论这件事。我不知道系统的细节，但只要你使用HUGE这个词，Domain Model就会成为最明显的选择。答案 2 :(得分：1)
除了Paul T Davies和Magnus Backeus所说的内容之外。我认为，在一天结束时，这将是一个人和文化问题。如果人们思想开放并且愿意学习，那么说服他们相对容易。如果他们认为你是一个“初级”（这是一个不好的迹象，因为唯一重要的是你说的不是你多大年纪/经历过），你可以诉诸“更高权威”：
存储过程已经失效，您不是only one who thinks so：
令我们震惊的是，我们在2011年继续寻找新系统 在存储过程中实现重要的业务逻辑。 通常用于实现存储过程的编程语言 缺乏表现力，难以测试，并且不鼓励干净 模块化设计。您应该只考虑执行存储过程 在特殊情况下，在数据库引擎内 是一个经证实的性能问题。
说服那些不愿意改进和学习的人是没有意义的。例如，即使你设法赢得一个论点并挤进NHibernate，他们也可能会像以前一样编写相同的紧密耦合，不可测试，面向数据或linq的代码。 DDD很难，它需要改变许多假设，伤害自我等等。根据公司的规模，这可能是一场不值得入手的持续战斗。
Driving Technical Change是可以帮助您解决这些问题的书。它包括您可能遇到的几种行为刻板印象：