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 2

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
One of the changes
As I said, it’s been a long time since part one was written. I have not spent all of that time thinking about this architecture (or resting), but some thoughts did occur to me. One of them was to drop EntityCollectionBase. This wasn’t an easy decision, and I’m definitely not sure that it will be this way forever. Anyway, I found myself in one of those situations where I couldn’t see which way to go. After a while I found out that I was stuck. In order to get going, I had to make a decision.

I decided to drop EntityCollectionBase for the following reasons:

+        Complexity added without any real benefits
At least no real benefits for the moment. I found out that I was just adding dummy code for creating the typesafeness of the collections. Since I’m (sometimes) a bit XP[3]-influenced, nowadays I don’t like to add stuff on beforehand that I only might need later. I also think that simple is beautiful is a very important principle for design.

In a way, the DataTable of ADO.NET is quite nice as far as this goes as it describes both a row and rows. (However, as I said in the previous article, there are other problems with it.)



+        ReadOnly-problem
At first I couldn’t find a really good solution for how to expose a read only collection from when a customer has a collection of orders. The main reason for the problem was that in my early tests I inherited from CollectionBase. There is a ReadOnlyCollectionBase to inherit from instead, but I didn’t want any such restrictions internally in the Customer class, only externally. Using ArrayList, for example, gives a simple solution to the problem. Just use ArrayList.ReadOnly(theListToExpose) and you’re done.

On the other hand, I could skip CollectionBase and instead implement the necessary interfaces myself. That was actually my plan. I mean, just to start with CollectionBase, but change later on. Have a look at .NET CollectionGen[4] by Chris Sells et al.

+        Increased serialization problems
I started to suspect that I couldn’t manage to stay with plain serialization for moving domain model objects between remoting end points, and would need to write custom serialization code, even for pretty simple object models. By simplifying the solution and not relying on events (or similar) constructs, I have at least simplified the serialization problem.

+        I started to think that I needed a new toplevel class
EntityBase and EntityCollectionBase had a lot in common, so I started to think that they should both inherit from a new superclass. On the other hand, at the same time that felt a bit unnatural, and also like over-design. I decided this was a sign that I needed another solution.

+        Sometimes I need an ArrayList, sometimes a Hashtable, and so on
So, in reality I would probably need not just one EntityCollectionBase, but rather several different flavors. And then there was the problem of whether I should create one OrderCollection that inherits from EntityCollectionBase and one that inherits from another custom superclass and so on.



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