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 4 : Page 5

This is the fourth in a 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.


advertisement
Types of Parameters
One thing that I have avoided touching on so far is what kind of parameters to use when fetching single objects. The main reason for avoiding this was the ..AndRefresh() style of interface used last time. Now, when I have changed to, say, SaveCustomer()/FetchCustomer() instead, I have to decide on the parameter type for FetchCustomer() and FetchOrder() and so on.

My first idea was to use ordinary objects here too, such as Customer objects with present key values. Note, for example, that FetchCustomers() uses a query object as its parameter and the query object has all the important information (criteria) needed for the query to be executed. By sending a customer object as parameter to FetchCustomer(), the same pattern is used again and the customer object will have all the criteria information (the primary key value) that is needed.

I first thought I could argue for sending ordinary objects (such as Customer instances) by pointing to the Introduce Parameter Object refactoring [9], but I changed my mind about that. That refactoring is more about creating classes of related values that are used as parameters. The Customer class is not created just because of the parameter requirement. It’s already there and is designed to do other things than just be used as a parameter containing the key value.



So, what’s the problem with the object approach then? Well, it feels a bit wasteful to send a full fledged object, when there’s actually only one single property that is interesting. This is especially the feeling if there is an AppDomain boundary to be passed so that the whole object will be serialized and deserialized.

I could solve this by providing yet another form of unexpanded state of the object, having only the key value, but this adds to the complexity and it means a lot of work for a minor benefit. Another thing is that remoting creates a problem here because the object you get back is not the same as the one you sent.

I’ve mentioned the problem with remoting a couple of times and I’m still not done with it. As you’ve probably guessed already, this bothers me.

So, what is it that I’m really after? Well, the most important thing is that I don’t want to spread information about the key structure everywhere, especially not in the consumer tier. On the other hand, if all the keys are GUIDs, then it’s not that much of a problem to let the consumer know about the datatype. It’s not very likely that you will outgrow the GUID datatype, for example, and have to change it as a result Even so, it’s nice to encapsulate the information about the key datatype from the consumer if you have to change it, especially if you start with a smaller datatype. Remember, one of the main reasons for the new architecture was to provide a higher degree of encapsulation of the database so that it can evolve more easily without affecting the rest of the application



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