How to make domain model objects observables ?

[baptiste]

Hi all,

I'm the architect of a recently started J2EE project. We're heading towards a canonical layered architecture, with SLSBs and MDBs as facades delegating work to POJOs (services) accessing the domain model objects. Clients are remote Swing-based thicks apps (webstarted) and a RDBMS is used for data storage. The chosen appserver is JBoss 4. I've started playing around a bit with Spring and Hibernate (both of which I didn't practiced before) and I begin to understand the fundamentals.

Now for my problem: I'd like to make our domain model as feature-rich as possible. In particular, certains of its objects should be made observable in order to dynamically react to data modification.

I know about the classic GoF observer pattern and its Java implementation. This is observation of instances of a class. Since Spring/Hibernate is in charge of domain model classes instanciation (getHibernateTemplate().load(XXXclass...))), I can't figure out how to make all of them observable by one or many instances of other classes. AOP maybe ?

I'm new to Spring so be indulgent if the answer is trivial.
Thanks in advance for any clues,

Baptiste

[thomasw]

Hi Baptiste,

Use Model or similar facade objects as a central point of control for your models. These should exist and operate per-session, if changes and observation are to be per-session.

Then my recommendation would be to route your change reporting and observation through this, as a central point. Your Model object will quite possibly fill two roles; both Data Access service facade and observation central control point.

As far as canonical layered J2EE architecture goes, people have a lot of success with simple solutions. Data Access services providing the point of control, model objects travelling to the client, multi-headed lightweight containers eg Tomcat, etc.

What architecture really needs is points of control; you don't need to produce completely separate implementations between layers, you just just need a single reliable point of control where you *can* separate them if this becomes needed.

Said point of control scarcely even needs to do anything, it just needs to be placed there and have everything routed through it. This enables you to implement separation/ alternative transfer channels etc in the future, if these become required.

You really really want to avoid getting bogged down with this stuff.


Cheers,
Thomas
www.powermapjdo.com