• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java EE 5 and JPA design issue about how much logic do use in entities?

 
Kenneth Gustafsson
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'll get straight to the topic.

Problem scenario:
We're creating an application where we want to be able to create dynamic search queries using our own custom domain language, which we call Customsearch.

One class is responsible for these Customsearch queries and is in charge of their name, definition and interpretation. As an SQL database doesn't know about the Customsearch language our class must also be responsible for processing a Customsearch query and giving us back the SQL query representation.

So far so good. We have something similar to this UML class representation:
*---// UML Start*
-----
CustomsearchQuery
-----
name: String
definitionInOurOfSearchLanguage: String
-----
setName(newName:String):void _may raise exception_ +InvalidNameException+
setDefinition(newDefinition:String):void _may raise exception_ +SyntaxErrorException+
getName():String
getDefinition():String
transformToSql():String
-----
*---// UML End*
To manage all these CustomsearchQuery instances we have a manager class called CustomsearchQueryManager. Its UML representation is something similar to:
*---// UML Start*
-----
CustomsearchQueryManager
-----
customsearchQueries: List<CustomsearchQuery>
-----
updateCustomsearchQuery(CustomsearchQuery):void _may raise exception_ +NameCollisionException+
getCustomsearchqueries(): List<CustomsearchQuery>
getCustomsearchQuery(nameOfQuery: String): void _may raise exception_ +NoCustomsearchQueryWithNameException+
-----
*---// UML End*

We have a need to persist all these CustomsearchQuery instances which makes the class en entity. *What's your opinion on having logic in an entity?*

+My personal thoughts on the matter:+

I think that having the logic together with the attributes makes for a better object oriented design. As one of the key aspects of OOD is that each class should have their own responsibility. If we separate out the logic into another class the data and behavior (processing of the data) would be separate as well, which violates encapsulation.

At the same time. If there's something inherently bad with having logic inside entity classes. Then there really is no option. If that is the case I would think that having a parallel structure of the form CustomsearchEntity, CustomsearchLogic would be the best approach. It will be harder to maintain than having logic and data together, but at least we don't let one class control the behavior of many different types of "data objects".

Thank you for your time reading this! I'll appreciate any comments.
[ February 29, 2008: Message edited by: Kent Larsson ]
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I think what you're discussing is the anemic domain model anti-pattern. Take a look at Martin Fowlers discussion on the topic.

The Anemic Domain Model


AnemicDomainModel design 25 November 2003 Reactions

This is one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we've both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing.

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.


-Cameron McKenzie
 
Kenneth Gustafsson
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your answer! Yes it looks like that's the name and defenition of the issue I'm concerned about if we separate out the logic from our entity beans.

As also was said:
I don't know why this anti-pattern is so common. I suspect it's due to many people who haven't really worked with a proper domain model, particularly if they come from a data background. Some technologies encourage it; such as J2EE's Entity Beans which is one of the reasons I prefer POJO domain models.


It seems like the J2EE 1.x way of doing things encourages this way of designing. Are things any different with entity beans in Java EE 5? I guess the question I'm looking for is: Can anyone name any reason why we should separate the logic from the data and have our entities as pure data containers?

[ February 27, 2008: Message edited by: Kent Larsson ]
[ February 27, 2008: Message edited by: Kent Larsson ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35716
412
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kent Larsson:
It seems like the J2EE 1.x way of doing things encourages this way of designing. Are things any different with entity beans in Java EE 5? I guess the question I'm looking for is: Can anyone name any reason why we should separate the logic from the data and have our entities as pure data containers?

The only reason I can think of is the fear that the JEE spec will change again. This is the third major revision of what entity beans (now JPA) look like. Migrating is a pain even with a tool. People who have already been burned twice are more likely to want to keep logic out of JEE classes.

I don't think this is a good reason though. Since entities are now just Java classes, they can live on even if the JPA spec changes drastically. Just remove the annotations and we have a regular Java class that can be used as a regular object.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!