from domain model to transaction script

Question

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.

Answer 1

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...

Answer 2

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':

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

Stored procedures are dead and you are not the only one who thinks so:

It is startling to us that we continue to find new systems in 2011 that implement significant business logic in stored procedures. Programming languages commonly used to implement stored procedures lack expressiveness, are difficult to test, and discourage clean modular design. You should only consider stored procedures executing within the database engine in exceptional circumstances, where there is a proven performance issue.

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:

• The Uninformed
• The Herd
• The Cynic
• The Burned
• The Time Crunched
• The Boss
• The Irrational

Good luck!

Answer 3

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.