Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...

I've been working exclusively alone on a project for a while and have as much liberty as any developer could hope for. I'm a blessed man. Nonetheless, I have tried to kind of "pretend" like I am working in a team environment that has regimented deadlines. This is mostly due to integrity and partly due to prevention for laziness...how easy is it to constantly be researching solutions without implementing them?

There was a necessary period of growth in skill sets that had to occur and while I certainly haven't 'arrived' at some point the rubber has to hit the road and instead of striking out to google for an answer first, there must be some confidence on the toolkit that has been developed. A car has to at least be moving before turning the wheels even in the right direction will make any difference.

So design decisions whether regarding overall architectural structure or about simple object creation aren't strictly design decisions, but are really business decisions. Maintainability is almost at the top of my list for development ; partly because it's just fun to meet the challenge, but also because I work alone and I could be buried with feature requests if I am not careful to write robust, scalable code. Still, this goal has a way of stalling design decisions if you're not careful.

Realigning my thinking into Test Driven Development has largely stumped this phenomenon. Most importantly because TDD isn't about the tests, but meeting requirements in a iterative, thoughtful way.

An example of this came up for deciding how I am going to query my DB using NHibernate as my OR/M. Now, I am using an IRepository for controlling access to the NHibernate implementation of data access and this brings along a whole sweet suite (excuse me) of tools that are a snap to use. I need to create Query Objects to get the data I need in my domain, but do I really want to wrap so much that NHibernate already does for you? For example, do I need to wrap every ICriteria implementation with my own custom implementation to avoid the dependency on NHIbernate's API?How far does one take isolating a domain from specific implementation of these tools?

There seem to be at least three options:

  • Have more specific IRepository<T> implementations that expose methods like "GetCustomerByNameAndGender(string name, Gender gender)", perhaps in CustomerRepository:IRepository<Customer>
  • Create an Object Query language as I go that accepts calls maybe with fluid interface calls like .Where(PropertyName name) and so on
  • Respect the Single Reponsibility Principle and use NHibernate's API within the Domain, but only within query objects.

The first option really just moves the complexity into different area. Maintaining a million little methods really misses out on the joys of Object Oriented thinking where you can treat tasks as things and have adaptable code. The second option is tempting at first, but this is where the business man in me has to speak up and question the wisdom in this route. Do I really want to write a parallel Object Query language just for the sake of independence from an external tool's API? I think this is called "not created here" (or something like that) syndrome, right?

So, after weighing my options, I very simply refactored my implementations of IQuery<T> to use the rich NHIbernate API and my Domain Entities use these objects that fill a collection of ICriteria objects, IProjection types and so on. MY IRepository<T> accepts any object of type IQuery<T> and returns the results I need. If I ever need to switch to a different OR/M provider I'll have to write implementations of IQuery<T> that speak that ORM's language. Really, if I am making that kind of change to an application, this level of adaption seems acceptable.

One tool that can keep these changes from affecting my service layer is some kind of Dependency Injection container that gets the appropriate instance for me at runtime. So instead of instantiating IQuery<T> implementations directly from, say, a higher service layer, I can invoke Castle or Structure Map or whatever to get the instance that I configured. These kinds of tools are perfect for these situations.

OK ...back to coding. Posted on Saturday, September 30, 2006 12:29 PM O/R Mappers , OOP, Patterns, Architecture , Domain Driven Design (DDD) | Back to top


Comments on this post: When Design Decisions Aren't

# re: When Design Decisions Aren't
Requesting Gravatar...
I remember reading something like this (from either Fowler or Evans) on creating wrapper-like Query objects, defined in the Domain, that use whatever you want, custom SQL, HQL, or List comparison.. etc.

I like this approach because your consumer still has no idea that you're using NHibernate, and that is a good thing if you want the flexibility to easily change it later (if you'd ever want to do that).

This is really more appropriate when talking about a design that already uses datasets and plain-jane ADO.NET to accomplish data-access. If you can encapsulate and unify this method of DAL, then switching to a powerful ORM will be that much easier.
Left by Ben Scheirman on Oct 02, 2006 5:31 AM

# re: When Design Decisions Aren't
Requesting Gravatar...
do you have some sample code? About to start implementing doamais search using NHibernate.

Thanks
Peter
Left by Peter Karouzos on Nov 13, 2007 5:26 AM

# re: When Design Decisions Aren't
Requesting Gravatar...
this is really good idea for designing.
Left by essay help on Jan 08, 2010 6:37 AM

# re: When Design Decisions Aren't
Requesting Gravatar...
Thanks for this.
Left by Sell Gold on Jan 15, 2010 11:00 AM

# re: When Design Decisions Aren't
Requesting Gravatar...
Thx for sharing
Left by frezy on Oct 08, 2010 6:46 AM

# re: When Design Decisions Aren't
Requesting Gravatar...
Nice blog
Left by karma dla kota poznan on Oct 21, 2010 11:33 AM

Your comment:
 (will show your gravatar)


Copyright © Mike Nichols | Powered by: GeeksWithBlogs.net