aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Granularity for entities Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Granularity for entities" Watch "Granularity for entities" New topic
Author

Granularity for entities

Antonio Fornie
Ranch Hand

Joined: Aug 07, 2008
Posts: 117
Hello!

First of all, I'm going to talk and ask about something I was reading:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeEntity.html

Among other thing it sais "When the entity beans are fine-grained, each entity bean instance usually represents a single row in a database. This is not a proper application of the entity bean design, since entity beans are more suitable for coarse-grained components. Fine-grained entity bean implementation typically is a direct representation of the underlying database schema in the entity bean design. When clients use these fine-grained entity beans, they are essentially operating at the row level in the database, since each entity bean is effectively a single row. Because the entity bean directly models a single database row, the clients become dependent on the database schema."

I really disagree at all. May be in EJB prior to 3.0 and because of home/remote interfaces complexity and so on, it was a bad idea to have fine-grained entities, but not know. I think entities (no matter if it's Hibernate, JPA or whatever) should usually be fine-grained and mapped to tables, having a different row for each instance. In other words, each entity is a domain model class. Relationships between two entities are the same as relationships between domain model classes in my design.

So for example, a customer class would be an entity and would be fine-grained : getName(),getId(),getPostalCode()...

I agree their idea for distributed services, they must be coarse-grained and send complete entities, instead of sending properties one by one. So a remote service, ie CustomerService, wouldn't show fine-grained methods (getName(),getId(),getPostalCode()...), but coarse-grained methods like getCustomer(int customerId):Customer, returning the whole entity. Let's say in the remote machine is not necessary an entity but a Transfer Object, anyway...

What do you think? Anyone arguing why to entities shouldn't be fine-grained?

Thanks!


I feel there must be far better ways to do what I do... that makes learning even funnier
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
A single business Entity can consist of data from multiple database tables and multiple rows of data.

A key point that the author makes is "...the clients become dependent on the database schema." Client applications
should not be effected by any changes to database implementation. So, if you can maintain this aspect with a fine-grained Entity
implementation, then it is fine.

However, your focus needs to be on the business requirements and the best way to model business entitites in terms of OO paradigm, not
the database implementation.

For business Entities, such as described above, a fine-grained design is problematic. Typically, in real-world scenarios, business entities are not
simple and do consist of disparate data.
Antonio Fornie
Ranch Hand

Joined: Aug 07, 2008
Posts: 117
"However, your focus needs to be on the business requirements and the best way to model business entitites in terms of OO paradigm, not the database implementation." I agree, I never focus on database implementation, in fact I design DB schema focusing on business model: first of all I have my domain model POJOS, then every POJO representing data that must be persisted becomes anotated as @Entity. Usually I map every class to a table, if I have to map a hierarchy I usually use only a table for all classes in the hierarchy using discriminator columns, and for many-to-many relationships I create (or Hibernate creates) join tables.

Let's look at this (extremely simple) sample:

@Entity
class Customer{
int id;
String name;
Address address;
}

@Entity
class Address{
String town;
String street;
}

Please, I'd really like to understand how you'd do. May I ask you how would yo do something similar to this with a CompositeEntity and what concrete situations would you avoid?

I can imagine scenarios where client code would be coupled to this design (ie: myCustomer.getAddress.getTown()), but wouldn't it happen just the same with a CompositeEntity? Imagine that in the future we don't want to have a town for the address, is there any way not to have it coupled?

In fact, I find it usefull to have some kind of CompositeEntity encapsulating both the customer and the address, but even then my CompositeEntity would not be an entity, but a simple Composite with two inner entities. Right?

Thank you all in advance for answers and opinions.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Hi Antonio. My suggestion is if you are not working on legacy code that use Entity Beans, don't need to care about Entity Beans and Composite Entity pattern. Entity Beans are over-architected, they are remote objects but most people don't use remoteability feature for Entities, they don't support inheritance mappings, polymorphic queries, and EJB QL is god-awful (the specification doesn't support even upper, lower functions!).

When EJB 3 specification was being developed, the expert group tried to simplify Entity Beans, but they gave up, and came up with JPA which is POJO-based instead, Entity Beans was abandoned and left undeveloped and exist for backward compatibility purpose only.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Consider the following EntityBean class which provides an object-oriented representation of a business entity.

The relational records for bannedX5913Services and allowable87832Actions are stored in different tables.

The relational record for topMarketRankingDescription is also stored in a different table.

This single business entity contains multiple records from multiple tables.

In regards to the Composite Entity design pattern, there are many different ways that it can be implemented, not only one.




Keep in mind that the client object of an Entity EJB should always be a Session EJB. Entity EJB represent business entity "records" and Session EJB represent business workflow (aka business logic).

None of the objects residing in the Presentation tier should be considered "client" objects for an Entity EJB.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
James Clarks wrote:
None of the objects residing in the Presentation tier should be considered "client" objects for an Entity EJB.

I'll add that is because Entity Beans are remote objects, so when we're using Entity Beans we "have to" apply Transfer Object pattern (for performance reason).
JPA Entities don't have this problem because they are POJOs, presentation tier can use JPA Entities directly.
Antonio Fornie
Ranch Hand

Joined: Aug 07, 2008
Posts: 117
First of all thank you for your replies. I really learned from them.

I'm afraid I was talking about something different because I didn't understand at all the text. I thought it was talking about any Entity, for example, an Hibernate annotated pojo, or JPA pojo, not only old fashioned EJB Entities. That's why I said "May be in EJB prior to 3.0 and because of home/remote interfaces complexity and so on, it was a bad idea to have fine-grained entities, but not know". I mean, using Hibernate, JPA and the likes you don't have to worry about net concerns, because your pojos/entites are still local. But of course, in case of EJB prior to 3.0 you have to.

On the other hand, even when using Hibernate, in a really big and multi-module project, it could be still a good idea to have a class encapsulating some business beans/pojos/entities, but it would not be an entity, I mean, I would not annotate this kinda wrapper as entity, but each pojo encapsulated by it.

Having said that, the text does not only talk about net concerns, but coupling concerns. So even with Hibernate pojos/entities they say I should a CompositeEntity in order not to couple my clients, right? Well, in most of the projects I've worked I didn't use this kind of wrapper, because even using it I can't be sure the clients won't be coupled to the business model. Most of the possible changes would affect the clients anyway. And further, I don't think using a class per table set of entities means my design it's more coupled or more focused on DB schema. Don't agree?
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Like I said, if you are not using Entity Beans, no need to be interested much about Composite Entity pattern, from the Problem section, most of problems come from the fact that Entity Beans are remote objects.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Granularity for entities