Thursday, 14 January 2010

Observing the data layer

I've been busy separating out the data layer from the rest of the form code. First of all, I had the entity object owned by the data module. and holding a representation of the current record in when in browse mode. This entity object was exposed to the form, so it could be updated when the form was in insert/edit mode. After a while working with this I decided that it was the wrong way round. The entity object should be owned by the form and act like a 'jsp style backing bean'. When the form creates the datamodule, it passes a reference to the entity object so that the datamodule can use it as a source for data persistence.

This approach has a few benefits:
  • If I introduce a controller object, this can 'own' the entity object and pass it through to the form (view) and datamodule (model)... very MVC!
  • The form has greater separation from the Model.
Anyway, now onto the topic of the post: 'Observing the data layer'. Now that I have the data components separated from the form, I needed a mechanism to allow the form to refresh to the state of the datamodule. In the spirit of 'do the simplest thing that will work', I simply created an interface on the form class, exposing the existing event handlers for the handled data component events. Then, when the form creates the datamodule, I pass through a reference to this interface so the datamodule can 'call back' when it raises these events. This go things working. The next step was to then move code from these handlers that should be in the datamodule. This is the bit that has take me a while as the form and datacomponent code was nicely mixed!
Through this process I was able to remove some of the calls in this interface, where the code was entire database side. The remaining callbacks I renamed to give them meaningful form operation names such as 'ChangeViewState' and 'DisplayCurrentRecord'.

So now I have a form that doesn't contain any direct references to the database components and a datamodule that only operates the form via the designated interface. To further separate these two objects, I could go fully down the MVC route and implement the 'Observer' pattern. This would involve the form registering with the datamodule for data event changes. However, at the moment I don't think this is going to be necessary.

No comments:

Post a Comment