Chris Brandsma :
Second, my preference is to have one set of domain classes specifically for the data access (Repository Domain), and separate Domain classes for Views, and sometimes different domain layers for other layers, and have a robust mapping layer. This seems like a lot more work, but it actually keeps things much cleaner.

Do you have a code sample that demonstrate this? It’d be a lot easier to see this than to mentally map it out. I’d like to see the automapper/composition over inheritance action in code.

By the way, the comment system here is kind of wacky. I was lost at first because your replies started on one page and the original comment ended on another.

setTimeout( function(){
$(myDivForTheResults).load(“< %=Url.Action("Action", "Controller") %>“)
}, 5);

I have a question concerning the rule #7. In wich way or how do you use the setTimeout to call the load() function? Could you post an example or something like that?

Thanks a lot.

Great article and very sound advice!

I hope you don’t mind, but I intend to make quite a few references to your article in my talk at mvcconf.com next week to demonstrate how the Spark View Engine can help you achieve a lot of what you talk about here. If that’s a problem for you, would you mind letting me know by email?

All the best,
Rob

Demos to not equate good coding practices.

But, I will say this in defense of that method: if you can code the site, start to finish, in under 4 hours then I don’t care what your code looks like. Worst case you can rewrite the entire thing later. If your project is going to take days to complete, then an ounce of prevention is worth a pound of cure.

I saw an interesting variation in one of Scott Guthrie’s screencasts where he was using Linq or EF and everything was in one project. He was therefore able to use a partial class for the domain model which included all the validation rules and UI hints. This approach will not work using separate assemblies because partial classes have to be in the same assembly but it is an interesting option for smaller-scale projects.

So my CustomerInvoice would NOT inherit from Customer (or anything for that matter), but instead would have a Customer property. What inevitably happens when you start using domain class inheritance is that you get domain classes with more crap properties than valuable ones. Plus, now to hidrate the entity you have a tone more work that HAS to happen. Not so with composition.

Second, my preference is to have one set of domain classes specifically for the data access (Repository Domain), and separate Domain classes for Views, and sometimes different domain layers for other layers, and have a robust mapping layer. This seems like a lot more work, but it actually keeps things much cleaner.

But, in all fairness, my Domain (in the DDD sense) is not your Domain. Mine works very well for me. Not knowing your Domain, yours could work well for you, but not for me, and vise versa.

I particularly find interesting the ongoing discussion about rule #3 and what it means for the separation of concerns between layers. I think that inheritance should be used to build model classes.

Generic business rules should be coded in a base model class (ex: Customer) and presentation rules should end up in an inherited model class (ex: CustomerInvoice). In my example ‘CustomerInvoice’ class would have the responsibilities of formating customers fields and validate data for its use in the context of an invoice. ‘Customer’ class would also validate data but in the context of the business entity (ex: name should always be supplied no matter the context).

It could help maintainability and having classes closer to the data layer or to the presentation layer but not both while keeping most of the rules (business and presentation) out of the view. And its good OOP practice.