Ok, ‘Fat’ Model and Transaction Script both solve design problems associated with where to keep business logic. I’ve done some research and popular thought says having all business logic encapsulated within the model is the way to go (mainly since Transaction Script can become really complex and often results in code duplication). However, how does this work if I want to use the TDG of a second Model in my business logic? Surely Transaction Script presents a neater, less coupled solution than using one Model inside the business logic of another?
A practical example…
I have two classes: User & Alert. When pushing User instances to the database (eg, creating new user accounts), there is a business rule that requires inserting some default Alerts records too (eg, a default ‘welcome to the system’ message etc). I see two options here:
1) Add this rule as a User method, and in the process create a dependency between User and Alert (or, at least, Alert’s Table Data Gateway).
2) Use a Transaction Script, which avoids the dependency between models. (Also, means the business logic is kept in a ‘neutral’ class & easily accessible by Alert. That probably isn’t too important here, though).
User takes responsibility for it’s own validation etc, however, but because we’re talking about a business rule involving two Models, Transaction Script seems like a better choice to me. Anyone spot flaws with this approach?
consider moving some of the business logic into the service layer