Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Pure Object-oriented Domain Model by a DB Guy, Part 2 : Page 5

This is the second in a new series of articles by Jimmy Nilsson on a new architecture for enterprise applications in .NET. The new architecture is purely object- oriented, while still focusing on roundtrips and the data access code to get good performance. This articles delves into the most important base class for the new architecture.


advertisement
The Changes
I have touched on a couple of the changes I decided to make since writing part 1 (see left column) and here they are summarized:

No EntityCollectionBase

Well, this one has been discussed quite a lot by now, so let’s move on to the next change instead.



Everything via interfaces

You don’t have to use EntityBase at all. You can use interfaces instead. This is important if, for example, you want to use a superclass other than EntityBase.

Encapsulate Collection refactoring

Earlier, the order collection was fully accessible as a property in the Customer class. Now I have applied the Encapsulate Collection[9] refactoring. This means that consumers to the Customer class will only get a ReadOnly collection when the Orders property is used. AddOrder() is used on the Customer class for adding orders. Therefore the Customer class controls the collection (or whichever datatype that is used internally.)

IsValid() As Boolean

I have changed the Validate() signature over and over again, but now I have decided that it will return a Boolean and not raise an exception when a business rule has been broken. A broken business rule isn’t an exceptional happening. This gives a little smoother interface, but when you call to persist an object that isn’t valid you get an exception anyway. Then you have done something exceptional.

I also changed the name to IsValid().IsValidated() is not found as I don’t think it is needed as a public method any more.

No events about dirty going upwards

Earlier, all objects told their parents when they got dirty. I have now turned the responsibility for tracking changed children around, so the parent has to ask the children instead, if it wants to know.

One good thing about this is that it’s no longer a problem if HasDirtyChild() returns True too often. This was a problem before because the child object that was dirty might have become clean, so to speak. However, it wasn’t



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date