从领域模型到事务脚本
我开始的新地方刚刚开始从头开始开发一个全新的产品。他们正在应用程序服务中使用事务脚本，完全愚蠢的实体，以及带有存储过程的手动 DAL（争论点是 nhibernate 不能很好地优化 sql，加载太多东西，不能很好地扩展到大型项目等） ）。该应用程序应该是一个巨大的项目，只是处于起步阶段。
我之前的职位是做领域模型，所有业务逻辑都封装在其中，而应用程序服务仅处理基础设施+使用 nhibernate 加载模型并编写脚本。
我真的相信采用第二种方法要好得多。我本来打算做一个关于原因的演讲。我有很多书籍/文章/个人意见可以支持这一点……但作为一个“初级”，这可能没有多大意义（我也是我最后一个地方的单一开发人员）。
我正在寻找的是来自更资深人士的一些经验/技巧/失败项目的示例，为什么使用事务脚本/手工滚动 DAL 不是正确的想法。
The new place I started at is just starting to develop a completely new product from scratch. They are going transaction script in application services, completely dumb entities, and a hand rolled DAL with stored procedures (the argument is that nhibernate doesn't optimize sql well, loads too much stuff, doesn't scale well to huge projects etc etc etc). the app is supposed to be HUGE project just in it's infancy.
I'm coming from a position where I was doing domain model with all business logic encapsulated in that and the app services only handling infrastructure + loading up the model with nhibernate and scripting it.
I really believe going with the 2nd approach is much better. I was planning on doing a presentation on why. I have plenty of books/articles/personal opinions that I can back this up with...but being more of a "junior" there it might not mean much (I was also the single dev at my last place).
What I'm looking for is some experience/tips/examples of failed projects from more senior people why going transaction script/hand rolled DAL is not the right idea.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除了 Paul T Davies 和 Magnus Backeus 说过。我认为归根结底这将是一个人和文化问题。如果人们思想开放并且愿意学习，那么说服他们就会相对容易。如果他们认为你是“初级”（这是一个坏兆头，因为唯一重要的是你所说的内容而不是你的年龄/经验），你可以向“更高的权威”提出上诉：
存储过程已死，而您不是 只有一个人思考所以：
说服那些不愿意改进和学习的人是没有意义的。例如，即使你设法赢得一场争论并挤进 NHibernate，他们最终也可能会像以前一样编写紧密耦合、不可测试、面向数据或 linq 的代码。 DDD 很困难，需要改变很多假设，会伤害自尊心等。根据公司的规模，这可能是一场不值得开始的持续战斗。
推动技术变革这本书可能会帮助您处理这些问题。它包括您可能会遇到的几种行为刻板印象：
祝你好运！
In addition to what Paul T Davies and Magnus Backeus have said. I think that at the end of the day it would be a people and cultural issue. If people are open minded and willing to learn it will be relatively easy to convince them. If they consider you a 'junior' (which is a bad sign because the only thing that matters is what you say not how old/experienced you are) you can appeal to a 'higher authority':
Stored procedures are dead and you are not the only one who thinks so:
There is no point in convincing people that are not willing to improve and learn. Even if you manage to win one argument and squeeze in NHibernate, for example, they may end up writing the same tightly coupled, untestable, data-or-linq-oriented code as they did before. DDD is hard and it will require changing a lot of assumptions, hurt egos etc. Depending on the size of the company it may be a constant battle that is not worth starting.
Driving Technical Change is the book that might help you to deal with these issues. It includes several behavior stereotypes that you may encounter:
Good luck!
硬币总是有两面。
他们可能有一些关于 Nhibernate 和性能问题的观点。但总有解决方案，例如加载策略，您可以准确地告诉 Nhibernate 应如何处理特定的关键查询。
通过加载策略、缓存和 SQL 索引调整，您可以在性能方面取得很大的进步，真的很远。
但 ORM 的真正好处是它减少了代码库并使其更加 DRY。使您的系统更易于维护。它还减少了“层”，因为您不需要存储过程。
我参与过像你这样的几个项目，相信我，他们面临着维护问题
* 应用程序服务中可能存在冗余代码，因为您没有可以将逻辑放在一处而不是出现在多个应用程序服务方法中的域核心。
包含多个存储过程的巨大 DAL 层。
逻辑很容易滑出到 GUI
我可以使列表更长...但我的观点是，人们有时倾向于选择事务脚本，只是因为它很容易理解，首先而且，表现也很好。
但通常当顾问、员工离开项目并由维护团队接管时，就会出现问题。通常并不清楚应该在哪里进行更改，而且我见过的大多数 TS 应用程序都在架构上被滥用。它们从一开始就是很好的应用程序，但自从邀请您将逻辑放入 SP、服务、GUI 中（因为缺乏受限的 API、接口等）。
你跟着我吗？
/Magnus
p.s 您可以通过 CQRS 方法获得出色的性能和 DDD...
Well there is always two sides of a coin.
They may have some points regarding Nhibernate and performance issues. But there is always solutions to that, like load strategies where you tell exactly how Nhibernate should tackle specific critial queries.
With load strategies, caching and sql index tuning you can get far regarding performance, really far.
But true benefit with ORM is that it reduces code base and make it more DRY. Makes your system more maintainable. It also reduces a "layer" since you do not need stored procedures.
I've been in several projects like you, and trust me, they face mainaince problem with
* probably redundant code in application services since you do not have a domain core that can put logic at one place instead of appearing in several application services methods.
A huge DAL layer that includes several Stored procedures.
Logic easily slips out to GUI
I can make the list longer... but my point is that people tend to choose Transaction script sometimes just because it easy to understand, to start with and, well can be good at performance.
BUT usually the problems occur when consultants, employees leave project and maintanence team takes over. There is often not cristal clear where changes should be done and most TS application I've seen has been architectural abused. They were good apps from the begining but since the invite you to put logic in SP's, services, GUI (because of the lack of restricted API, interfaces etc).
You follow me?
/Magnus
p.s You can get great performance and DDD with CQRS approach...
我想说，采取材料来支持它是可行的方法，这样他们就不能用你的缺乏经验作为论据（尽管在我看来，你并不是特别缺乏经验或初级！）。我的主要推荐是这本书：
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 是开发人员错误的最大点。
就像马格努斯说的那样，我可以继续说下去。我不知道系统的细节，但是一旦你使用“巨大”这个词，领域模型就成为最明显的选择。
I would say taking material to back it up is the way to go, that way they can't use your inexperience as an argument (although it sounds to me that you are not particularly inexperienced or junior!). My main reccomendation would be this book:
http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X/ref=sr_1_1?ie=UTF8&qid=1317121019&sr=8-1
On page 146, it states:
'TS is suited for simple scenarios where the business logic is straightforward and, better yet, not likely to change and evolve.'
This does not describe the system you are working on.
It then goes on to describe Domain Model, and why it is suited to bigger systems.
I would question whether thay understand that it is Transaction Script they are opting for? In my experience, TS can often be the default choice for inexperienced organisations who don't even understand that there is even an option. They just think 'that's how it's done'. How successful and maintainable is their current code? If they are choosing TS for huge projects, my guess would be 'not very'! Do they blame the client for changing specifications when things go wrong? If so, this is an indication that their choice of architecture is wrong.
In my experience, the overhead in implementing Domain Model is minimal. And it is a lot less painful than trying to scale and maintain a badly architected system.
Also, in this day and age, database servers should be able to handle systems based around NHibernate with no problems. If it can't, then that is a problem with the database server. And how do they intend to unit test these stored procedures? I usually find SP are the single biggest point of developer error.
Like Magnus said, I could just go on and on about this. I don't know the details of the system, but as soon as you used the word HUGE, Domain Model becomes the most obvious choice.