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

This is the fifth part in a series of articles by Jimmy Nilsson on a new architecture for enterprise applications in .NET. The new architecture is purely object-oriented with maintainability as the number one goal, while still focusing on roundtrips and the data access code to get good performance. In this article, Jimmy will discuss the new architecture from a persistence access layer perspective.


advertisement
Need for the Delegate Solution?
Well, there might be situations when you need the old solution with the delegate, but for the most part I dont think you do. If you do need it, you have to add the methods again that I have dropped from the Unit of Work classes. Those were AddResultHander(), ExecuteReturnEntity() and ExecuteReturnList().

Query Object
I touched upon the Query Object [5] several times in part 3 [3] and 4 [4] where I showed how to use it for setting criteria in Query Object instances.

The purpose of the Query Object [5] pattern is to encapsulate all information for a query that is needed to execute the query against the database.

As you saw in Listing 7, I then take out the criteria information from the Query Object, and use the criteria values directly as parameters to my stored procedures. Of course, this is just an example and a simple one at that, but you can use this solution as the basis for solving much more complex problems too.



As you might remember, in part 3 [3] I also used the CustomerQuery for consumer-side filtering, so you dont only have to use Query Objects when accessing the database, of course.

My current implementation of Query Object classes such as CustomerQuery inherits from the MustInherit class QueryBase. You'll find the QueryBase class and an example of a subclass (CustomerQuery) in Figure 4.

Figure 4 The QueryBase class

As you saw in Listing 7, Criteria() is used for taking out criteria values from the Query Object. Also note that the AddParameter() methods of the Unit of Work classes use named parameters (for example @myParameter='TheValue') when calling the stored procedures. Because of this and as a result of default values for the parameters in the definitions of the stored procedure, its okay to not set all parameters explicitly in the call.

How are criteria set? By setting WriteOnly properties of subclasses such as setting CustomerNo in Figure 4 to the value 5, for instance. Finally, by letting the Query Object support consumer side filtering too, the subclasses must override the Match() method.

So, to implement a Query Object, what you have to write is the code for the criteria properties and the Match() method. An example of that code is found in Listing 9.

Public WriteOnly Property Name() As String



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