There are multiple tables in my database. Each table has a primary key, and the table that relates to other tables has foreign keys. I have to match the primary key and foreign key to go from one table to another. The specifics are spelled out below:
The first table has login, pwd, and a primary key as fields, the second table contains completely different fields plus a primary key and foreign keys. The fields in the third table are different from those in the first and second tables plus its primary key. Queries to the third table can be made only if the user login and pwd are found in the first table, and through the second table's relation to the first table and the third table�s relation to the second table. The fields of all those tables may be accessed concurrently, but the fields are "read-only" (for the time being). I have a servlet to handle browser interactions. And I have a session bean to handle the workflow and business logic. However, I am confused with the choices between VO and entity beans.
I first thought that I should use value objects to represent the data fields of the specific rows I looked for in those tables. Here is what I read about Value Object:
If a business object merely represents a structure to hold data fields, and the only behavior it provides are get and set method for the fields, then it would be wasteful of system resources to implement it as an enterprise bean. To avoid expensive remote methods calls (system resources and network bandwidth) to get the value of entity object fields, a value object is used to represent the details of the entity object. Only one remote call is required to retrieve the value object and then a client�s request to query the state of the object can then be met via local get methods on this details object.
On my second thought, I think I should use entity beans to represent the specific rows I am looking for in those tables because I must use primary key and foreign key relations to go from one table to another. I do not use DAO because I am using CMP. The first call is within the session bean. It is a remote call to look for a specific row in the first table in my database. Subsequently, the mapping of the row in the first table to the second table, and the mapping of the row in the second table to the third table are all invoked on the �local interfaces� of those entity beans. client(browser)-->front controller(servlet)-->session facade(session ejb)-->entity ejb-->entity ejb -- > entity ejb Please advise if this is the right design. Am I on the right track? Is there improvement to be made?
"Actual mileage may vary depending on driver and road conditions", as they like to day on the auto advertts. Or, in Inernetese, YMMV. Generally, I prefer to leave to logic out of the Entity beans. Hence, I'd do something more like:
It might be advisable under some conditions to have TWO entity layers - one for the business logic and one to provide the composite data facade. This mostly depends on how complex the logic is. Your objects are NOT literally "Value Objects" according to definition provided, since in addition to get/get, you'll be activating and passivating against the persistent storage. When all has been said and done, the "right" solution is the one that is A) easy to understand and maintain B) reliable C) performs in an efficient manner. I've found that these goals are not as mutually exclusive as is often though. In particular, usually a REALLY efficient solution is a clean one, because it has fewer kinks in it. Remember Fred Brook's advice: "Plan one to throw away". Don't consider your first effort to be the final one, since often the attempt to solve the problem points out a better way.
Loudly announcing something is true and finding out you're wrong makes you feel foolish.
Finding out you're wrong and refusing to admit it makes you LOOK foolish.
Tim, I appreciate your feedback. However, I might not explain my question well in my previous post -- there is no business logic involved in what I am doing to go from the first entity bean to the second entity bean and to go from the second entity bean to the third entity bean. Based on the login information, I have to go through those entity beans to find the very specific row in the third table in order to get the data field I need. That is to say, only thing involved is searching for rows. In my view, session bean -- > 1st entity bean -- > 2nd entity bean -- > 3rd entity bean 1. session bean -- > 1st entity bean: remote call and returns the key to the 1st entity bean for locating the 2nd entity bean 2. 1st entity bean -- > 2nd entity bean: local call and returns the key to the 2nd entity bean for locating the 3rd entity bean 3. 2nd entity bean -- > 3rd entity bean: local call and then returns the value of the specific field to the session bean Your suggestion is also what I have been thinking:
1. session bean -- > 1st entity bean: remote call and returns the key to the session bean for locating the 2nd entity bean 2. session bean -- > 2nd entity bean: remote call and returns the key to the session bean for locating the 3rd entity bean 3. session bean -- > 3rd entity bean: remote call and the session bean can get the value of the specific field from the 3rd entity bean I do not know which approach to go for. Please provide guidance. Thanks.