If I understand you correctly, you're describing exactly the same sort of pattern I have wanted to try as well. You start by adding one or two "friendly helper" methods to an entity, but when a system starts to grow large enough and touched by enough people those entities start to become utterly littered with business logic. You want to alleviate this by separating the entities from the surrounding business logic.
So, if you're describing the same sort of problem, then you want some form of architecture like this, I assume?
Code:
// Your "business logic wrapper"
class Item {
private ItemData itemData;
public Item(ItemData itemData) {
this.itemData = itemData;
}
// any relevant business logic for the Item class
}
// Your actual entity with simple getters/setters for data
class ItemData {
@Id
@Column(name = "item_number")
private String itemNumber;
@Column(name = "item_description")
private String itemDescription;
// just your standard getters/setters for modifications to persisted data
}
// And some form of DAO to read in Items from the database
class ItemDao {
public Item read(String itemNumber) {
ItemData itemData = session.read(ItemData.class, itemNumber);
return new Item(itemData);
}
However, your trouble is that when you have mappings between entities the wrappers will not be returned on the getter calls, correct?
I have thought about this problem and perhaps there is some form of Hibernate hook out there that I am unaware of. If so, then perhaps somebody a bit more knowledgeable than me will chime in here. However, another method I have personally considered to solve this problem that *seems* like it should be relatively straightforward is to abuse the @Embedded property in Hibernate.
In other words, do the above like this:
Code:
// Your "business logic wrapper"
class Item {
@Embedded
private ItemData itemData;
// any relevant business logic for the Item class
}
// Your actual entity with simple getters/setters for data
@Embeddable
class ItemData {
@Id
@Column(name = "item_number")
private String itemNumber;
@Column(name = "item_description")
private String itemDescription;
// just your standard getters/setters for modifications to persisted data
}
// And some form of DAO to read in Items from the database
class ItemDao {
public Item read(String itemNumber) {
Item item = session.read(Item.class, itemNumber);
return item;
}
This seems to have the added bonus of your "business logic" classes being seen as actual entities by Hibernate (which can be directly used in HQL) while still allowing for a proper logical separation between your business logic and your data accessors.
Again, this is purely academic in my head; I haven't had the opportunity to try this out in a large system so there very well could be problems I have not thought of. Still, if it works for you then please keep me updated!
Login
FAQ
Search