• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Chris POJO : How to POJO?

 
Kartik Shah
Greenhorn
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?

Thanks

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
-------------------------------------------------------------------------------
 
Chris Richardson
author
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kartik,

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.

Chris
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic