OO Domain concept realisation

mangrish's picture

Hi All,

I would just like to get some feedback on some techniques I use in my development. I'm not entirely happy with these so I am hoping there are better ideas out there that i can learn from.

With my PD objects that require persistance I typically use the following pattern:
* Create a PD class (for example lets say I have a class called FXInstrument)
* I then create a PD interface for it to interact with some sort of persistance mechanism (IFXInstrumentDao). It contains methods such as findAll(), findBy(Id), save(FXInstrument), delete(FXInstrument), update(FXInstrument).
* In the SI I would then have a realisation for this interface (something like CachedJdbcFXInstrumentDaoImpl). I really dislike ORM technology so i typically cache objects as i retrieve them inside this class myself (Contrary to popular belief it isnt that hard to write and maintain.

So what i have so far is something like:

IFXInstrumentDao ---------- FXInstrument
/ \

In the FXInstrument class I have a static variable that holds the Dao. Something like:
private static IFXInstrumentDao dao = DomainFactory.findImplFor(IFXInstrumentDao.class);

I then expose my PD object to others (rather then letting any other class know about my Dao). I typically don't require Description objects so i collapse those methods into my PPT objects. To be honest I have rarely used a Description object in the systems i have built. What i end up with is something like FXInstrument.findBy(Id) and FXInstrument inst = new FXInstrument(...); inst.save(); etc. These then delegate down to the dao. What i like about this is the detail about persistence is hidden from the client of that object.

Is this a good approach? Or is it ok to expose Dao's to other PD objects and SI/UI clients? What if one has heirachies (e.g. FXInstrument has subclasses like Spot, Future and Forward etc.) that also need persistance to different tables?. Would it be better to modify the static finder on Instrument to support finding by class as well? e.g. Instrument.findBy(Id, Class), or introduce more Dao's for each subclass and introduce a Description-like object to do things based on type?

Another question i have is around compound domain object instantiation and start up order. What if when building the state of my domain object on start up i run into compound construction issue.

For example, lets say that as part of building my FXInstrument object I require some configuration data (loaded from my database) and then some extra data from a 3rd party provider (SI component) in order to fully instantiate my object. At the moment i think creating something like a FXInstrumentConfiguration object to encapsulate the database side and then creating my 'real' FXInstrument class when i get my 3rd party information sounds ok, but it seems weird i would have a seperate dao for configuration outside of my FXInstrument class. An alternative might be to create a builder object and an in memory cache for it, then when the 3rd party data arrives simply look up the partially constructed builder and add the remaining data. I ask this question as during start up when i have PD objects that need other objects configured first before starting up themselves, partially constructed PD objects are a pain, especially in a massively multithreaded system. For example lets say i have listeners that need to be set up on my FXInstrument class. These can't be loaded from the database until the FXINstrument class itself is properly constructed! This introduces different kinds of dependency in that all threads and objects in the PD now need to know about a universal start up coordinator which can introduce barriers!

Any ideas anyone has are most welcome!

:: mark angrish

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ericjsilva's picture

Seems like a sound design...

Your PD <-- DAO pattern is straightforward out of any 'patterns' book out there. In the past I have used Hibernate or NHibernate as a persistence layer. I like ORM solutions, but at this point the concept is the same regardless of persistence implementation. I have also used the Factory pattern exactly as you have shown to wire a DAO implementation for the PD object; only that I prefer to use a IoC framework like Spring to manage the configuration. This allows me to inject different DAO implementations for unit testing (mock) and actual databases without having to modify the source code. This would also help you in the scenario where you have a PD that needs to be initialized from the database as well as a third party system via SI. I have done this before using an private initialize() method in the PD. The PD knows how to initialize itself. This can be called from within the constructor after all the typical property setting has been done.

As far as subclasses and persistence, this is the main reason I like ORM frameworks: you don't have to concern yourself with the details.