• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Chris POJO : How to POJO?

Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chris,

I have been working in Java since last 7 years and been very close to the evolution of Java and used them with different context and methologies.

As per my understanding POJO is a programming model.
I have 2 questions for you?

1. How to use/implement POJO in the context of AGILE Modeling? [Since we are following it, so very curious to know..]

2. What is the best way to re-architect/transpose/convert/migrate existing complex hairball of systems to this model?


Kartik Shah
Information Analyst
Electronic Data Systems (India) Pvt. Limited (India ADU)
Level 2, Tower II, Cybercity, Magarpatta, Hadapsar, Pune 411028
Direct: +91 - 20 - 5606 9059 Cell: +91 - 9890668244
Board: +91 - 20 - 5606 9000 Ext. 9059 Fax: +91 - 20 - 5606 9010
Em@il: kartik.shah@eds.com Visit us: www.eds.com
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I believe that agile modeling and POJOs work well together. In particular, POJOs and modern ORM frameworks such as Hibernate and EJB3 let you build complex domain models. Unlike, EJB CMP, they support inheritance and other kinds of rich relationships between objects.

I believe its possible to adopt POJOs in a mostly incremental fashion. For example with application, which used EJB session and entity beans application, we took the following approach:

1. We replaced all of the entity beans with Hibernate. It helped alot that we used the Two Level Domain Model pattern (http://www.theserverside.com/articles/article.tss?l=TwoLevelDomainModel), which separated the business logic from the Entity beans. Moreover, all of the database access code was encapsulated within DAOs.

In theory, with a larger domain model you could replace each connected subgraph of entity beans with Hibernate separately.

2. New code was written using Spring and Hibernate - this coincided with the beginning of v2 of the product so we were writing lots of new code.

3. As the need arose (e.g. old code needed to be enhanced or new code needed to call old code) we then converted each session bean into a POJO that used Spring for transaction management. It also helped that most session beans were true facades that delegated to an existing POJO manager.

There are certainly other ways to do the migration. And, some of what you do depends on the starting point. For example, if you have a lot code in your EJBs you could incrementally change each EJB into a pure EJB facade that delegates to a POJO that it gets from Spring. You could then either get rid of the EJB or continue to use it.

I hope this helps.

His brain is the size of a cherry pit! About the size of this ad:
the value of filler advertising in 2020
    Bookmark Topic Watch Topic
  • New Topic