Menu
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.
988
Organizes business logic by procedures where each procedure handles a single request from the presentation. For a full description see P of EAA page 110. Most business applications can be thought of as a series of transactions.
With Transaction Script the domain logic is primarily organized by the transactions that you carry out with the system. If your need is to book a hotel room, the logic to check room availability, calculate rates, and update the database is found inside the Book Hotel Room procedure.
Domain modeling is a great tool for Agile enterprise to carry out a common language and a fundamental structure important for the analysis of features and epics. The domain model is defined and continuously refactored as enterprise knowledge about the domain improves and the system functionality evolves.
The third and more complex solution for organising domain logic is a design pattern called Domain Model. The pattern provides an object-oriented way of dealing with complicated logic.
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:
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:
Good luck!
200
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...
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
