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!
Increase your productivity by avoiding the creation of Data Access Objects (DAOs) or EJB's - just expose your model the way object oriented applications were intended to work. DAOs and EJBs evolved to assist in the persistence of objects prior to the era of transparent persistence. Now that transparent persistence is omnipresent (JDO, Hibernate, JPA etc.,) the case for creating DAOs or EJBs in modern application is hard to justify. You build your domain model from pure POJOs (Plain Old Java Objects) and persist it transparently using exPOJO and the transparent persistence technology of your choice.
When Spring started out its main focus was to provide a simple to use dependency injection framework but now that it tries to do all things, including tackling the problem of global warming and finding a solution for world piece it's kind of lost its way in this developer's opinion. When all you really need is to expose the objects in your POJO based domain model and access a simple, easy to use, light weight dependency injection system with a miniscule learning curve then you've just met your new best friend, exPOJO.
exPOJO's abstracted PersistentProvider class forms a generic interface that you can use to access the persistence services of JDO's PersistenceManager or Hibernate's 'Session'. Accessing persistence services in this way gives your project a level of vendor independence that puts you in a position of power - especially if future technologies, like JPA, gain popularity. You can simply switch to a different PersistentProvider implementation to make use of different persistence technology.
exPOJO provides a very simple and lightweight but extremely useful and productive framework on which to build web or desktop applications using the 'exposed domain model pattern'. In addition to ridding developers of the DAO and EJB burden most exPOJO users find they don't even need to expose themselves to the learning curve of such heavyweight frameworks as Spring nor incorporate it into their applications, reducing development time and reducing jar dependency issues.
exPOJO works with frameworks like Wicket, Struts, Tapestry, Echo, Java Server Faces (JSF), Java Server Pages (JSP), raw servlets etc., exPOJO employs elegant, simple and concise dependency injection at the Java coding level - no need to learn a special dependency injection framework or configure yet another XML file.
exPOJO can now be used in commercial and open source applications without paying any licensing fees and you are not required to make your proprietary application's source code available. You have a choice of LGPL, BSD or Apache 2.0 licenses.
The exposed domain model pattern brings its own productivity gains but when you add exPOJO the productivity gains increase even further. exPOJO assists with implementation of the exposed domain model pattern by providing a number of useful coding and management facilities including a ModelExposer that you can extend plus simple management and access to your Service and Repository classes.
If you look at a project that uses exPOJO you might also notice something very subtle but very powerful: there is no code specific to JDO or Hibernate in any of the classes except for the repository classes. The application can do it's job completely via the methods available in the model exposer, its services, repositories and the model classes themselves. exPOJO has completely removed the need to access any classes of the persistence technology being used (JDO, Hibernate, JPA) directly. This means that you can switch between different persistence technologies with minimal changes to your UI classes and domain model classes, preventing vendor lock in. The only constraint is that you implement a Repository class specific to a persistence technology that you wish to use. You can also take advantage of future persistence technologies that have not yet matured (eg., JPA) when they mature while using a mature (JDO, Hibernate) technology for now.
Java framework creators make their frameworks much more appealing to a wider range of developers if their framework is flexible enough to work with multiple transparent persistence engines right out of the box or if adding support for a currently unsupported engine means only implementing an appropriate repository and not reworking most of the application classes.
With the ability to switch between different persistence technologies relatively easily you can test which ones enable your application to perform at it's best.
One or more repositories can be implemented in a project to provide methods for searching and locating existing objects in the datastore. You are free to code these how you like. They form an elegant, convenient search facility available to from your user interface classes or your domain model classes.
One or more services can be implemented in a project to provide methods for creating, deleting and modifying objects. Any service class should work with any persistence technology because it communicates with the underlying persistence technology via the interface provided by the generic PersistenceProvider class - which has both JDO and Hibernate implementations. Services become an intuitive location to implement business logic as they are used to create changes in the model. Business rules and checks can be implemented and applied within one or more services. As the services need not contain any persistence technology specific code your business logic remains instantly portable across a range of persistence technologies - which should keep you happy - and your boss even happier!