G
Gert Vanthienen
L.S.,
We're in the process of developing an application using JSF, Hibernate and Spring and we're facing a design question on which we would like your ideas.
The application has it's own database, which is accessed using Hibernate, for most of it's entities (e.g. Problem), but it also has to work with data from a legacy system.
The legacy data is accessed through a set of Spring components (<bean/>s), which use JMS to exchange XML messages with the legacy system. These services provide us with e.g. Article instances.
The Problem instances, which are retrieved using Hibernate, should hold a reference to an Article. Since Hibernate does not know about the Article class, we have added an articleId property to the Problem class and whenever we retrieve a Problem using our ProblemService class, the ProblemService will look at this property and retrieves the corresponding Article instance.
This process happens for a couple of entities (Article, Supplier, TracingInformation, ...)
This approach however has a number of drawbacks:
1) our Problem class contains several 'duplicate' properties: articleId/article, supplierId/supplier,... leading to confusion
2) resolving the correct Article, Supplier, ... instances happens for every Problem ever instantiated in the ProblemService, causing overhead whever the information is not required by the JSF web client (especially for lists of data)
3) whenever someone adds functionality to the ProblemService, we have to be careful to always fill in the missing entities when a new Problem instance is created
We have thought of two possible solutions so far:
1) creating a Hibernate UserType to convert the article id stored in the database to an Article instance and visa versa
- This approach would solve drawbacks 1 and 3, but doesn't help us much with drawback 2.
- There is another issue with this approach: we need Spring's ApplicationContext in our UserType (<type .../> declaration in Hibernate mapping), but this would require rebuilding the ApplicationContext or having some kind of singleton to obtain the ApplicationContext (it is now created by a web application listener) (unless there is a Spring way of doing this, e.g. using a TypeDefinitionBean)
2) creating a business delegate for the Problem class
- This would solve all drawbacks, since the business delegate could quite easily use the Spring components already available to retrieve an Article instance on the fly when needed
- The business delegate should only have to expose the article property and the object sent to our DAO should only contain the articleId
- The business delegate solve the resolving of the Article, Supplier, ... entities once and for all, so nobody can forget to add these to their newly created Problem instance
The 'Business Delegate' solution seems the most appropriate, but wouldn't it add a considerable amount of extra coding for the features it provides?
Which solution would you recommend? Do you see an easier solution for the problem?
Thank you in advance for any feedback,
Gert Vanthienen
(e-mail address removed)
We're in the process of developing an application using JSF, Hibernate and Spring and we're facing a design question on which we would like your ideas.
The application has it's own database, which is accessed using Hibernate, for most of it's entities (e.g. Problem), but it also has to work with data from a legacy system.
The legacy data is accessed through a set of Spring components (<bean/>s), which use JMS to exchange XML messages with the legacy system. These services provide us with e.g. Article instances.
The Problem instances, which are retrieved using Hibernate, should hold a reference to an Article. Since Hibernate does not know about the Article class, we have added an articleId property to the Problem class and whenever we retrieve a Problem using our ProblemService class, the ProblemService will look at this property and retrieves the corresponding Article instance.
This process happens for a couple of entities (Article, Supplier, TracingInformation, ...)
This approach however has a number of drawbacks:
1) our Problem class contains several 'duplicate' properties: articleId/article, supplierId/supplier,... leading to confusion
2) resolving the correct Article, Supplier, ... instances happens for every Problem ever instantiated in the ProblemService, causing overhead whever the information is not required by the JSF web client (especially for lists of data)
3) whenever someone adds functionality to the ProblemService, we have to be careful to always fill in the missing entities when a new Problem instance is created
We have thought of two possible solutions so far:
1) creating a Hibernate UserType to convert the article id stored in the database to an Article instance and visa versa
- This approach would solve drawbacks 1 and 3, but doesn't help us much with drawback 2.
- There is another issue with this approach: we need Spring's ApplicationContext in our UserType (<type .../> declaration in Hibernate mapping), but this would require rebuilding the ApplicationContext or having some kind of singleton to obtain the ApplicationContext (it is now created by a web application listener) (unless there is a Spring way of doing this, e.g. using a TypeDefinitionBean)
2) creating a business delegate for the Problem class
- This would solve all drawbacks, since the business delegate could quite easily use the Spring components already available to retrieve an Article instance on the fly when needed
- The business delegate should only have to expose the article property and the object sent to our DAO should only contain the articleId
- The business delegate solve the resolving of the Article, Supplier, ... entities once and for all, so nobody can forget to add these to their newly created Problem instance
The 'Business Delegate' solution seems the most appropriate, but wouldn't it add a considerable amount of extra coding for the features it provides?
Which solution would you recommend? Do you see an easier solution for the problem?
Thank you in advance for any feedback,
Gert Vanthienen
(e-mail address removed)