Patterns of Enterprise Application Architecture.
I tend to rely more on the Transaction Script model. The biggest problem with Transaction Scripts is the duplication of logic. But through copious amounts of refactoring, I can keep that at a minimum. Transaction Scripts allow me to treat one page as an application. It knows how to get the data it wants and how to display it. That's it. It doesn't use an object model that might have to make use of 4 other objects in order to get all the data you want to display.
[News from the Forest]
That's the approach we follow in DeKlarit. Your domain classes are not the usual 'normalized' domain classes, but unnormalized views of the data required in a transaction (i.e., the Order class has a CustomerName). The good news is that DeKlarit manages the 'duplication' itself, so you don't have to worry about it.
If you don't like it, you can also work with a more traditional Domain Model.
10:10:47 AM 
|
