Javelin: the JDJ 'World Class Award' winning, leader in visual, model driven Java development since 1996!
try it FREE for 15 days and realize the benefits and efficiencies of managing a POJO based domain model via live class diagrams instead of a plethura of text files.
exPOJO: feedback, contributions, questions, suggestions:
|expose your POJOs!|
Version 2.0.1 just released!
What is the "Exposed Domain Model Pattern" and why is everyone talking about it?
In a nutshell the Exposed Domain Model pattern avoids the time consuming, inefficient and error prone duplication effort required by other application architectures that involve the creation of a separate Data Access Objects (DAO) for each class in your domain model. In such architectures each DAO takes on the responsibility of persisting it's associated domain model class. Typically when you switch to a new persistence technology you rewrite each of your DAOs for that technology - but why have DAOs if you don't really need them?
The exposed domain model architecture provides three types of objects that can be accessed by an upper application layer such as the user interface: POJO model objects, Repository objects and Service objects
POJO Model Objects
In contrast to DAO based patterns the exposed domain model pattern leverages the 'transparent persistence' provided by modern persistence technologies such as JDO and Hibernate. By 'transparent' we mean that no code needs to be added to your Java source files to enable them to be persistent, hence they remain 'Plain Old Java Objects', POJO.
'Transparent persistence' has been the Holy Grail of OO developers since the early days of C++. By using the transparent (JDO) or almost transparent persistence (Hibernate) capabilities of these modern persistence technologies the exposed domain model pattern cuts down development time, results in many less classes and provides faster runtime performance.
This transparency allows the developer to create a domain model built up purely of POJOs that are written devoid of any persistence specific code (except in the case of Hibernate where a few simple methods need to be added to the source code to make the POJO 'persistence capable'). The benefits of having a completely pure POJO domain model, not tied to any persistence technology should never be underestimated.
POJOs are great! A domain model built up on POJOs is easy to compile, persistable by any transparent (or semitransparent) persistence technology and so aren't locked into any particular vendor's persistence technology. They are also much more easily tested using a "Mock" persistence provider - frequently used to speed up development by allowing testing of business rules and logic without having to create/modify RDBMS schemas or access a real database. Unit testing of business rules and business logic can be executed in memory orders of magnitude faster than using a real database.
Ok so you're now asking where does all the persistence technology specific code like queries reside when using the Exposed Domain Model pattern? It resides in the 'Repository' class or classes (for larger projects). A Repository class contains all of your query code written in your persistence engine's specific query language. You call methods of the repository classes to fetch things like a 'list of all organizations in a specific country' or 'find a user with the given username'. Repositories return individual domain model objects or collections of domain model objects as required by the nature of each query request method. The returned objects are always the real POJO model objects from which navigation to other related objects can take place using the natural Java '.' operator. Any related objects will be loaded automatically from the datastore when accessed if not already cached.
In a well designed exposed domain model application all code specific to a particular persistence technology resides in the repository classes. Then porting to a different persistence technology simply means reimplementing the repository classes for the new persistence technology instead of rewriting or porting your model object or DAOs.
Services are where you typically make changes to your model and are where most of your business logic and business rules should reside. Services access the exposed domain model objects directly and they use methods in the repositories. Service classes, like POJO domain model classes, should contain no persistence technology specific code which makes them instantly resusable with other persistence engines.
Service methods can be wrapped in a transaction by clever use of a transaction proxy service class so that either the whole operation succeeds or it fails (The Javelin Modeller+Coder has special features to allow the simple creation of a service's implementation and it's proxy). exPOJO supports nested calls from one service method to another to allow a kind of 'nested transactions' to occur but either the whole composite transaction will succeed or it will fail - there is no support for partial success of a nested transaction in exPOJO. The smart begin/commit/rollback methods of exPOJO intelligently handle nested calls without prematurely commiting the transaction.