Value Object (Bean) Design Issue

[bryan nelson]

Greetings,

I'm trying to figure out the best way to create some Value Objects (VOs) for a new project. I want to keep things object oriented but am having a tough time deciding where to store some of the data. I'm using Struts 1 and Java 5 for the record.

Let's say I have a large website that sells life insurance plans and allows users to manage them, etc. I of course have some standard objects like userVO, planVO, etc. that I use to display data on different pages. Also, each of the pages will have x number of headers, y number of subheaders, z number of section names, etc. -- basically a bunch of strings that would normally either be hardcoded into the jsp or else placed in a properties file somewhere (like applicationResources.properties for example).

However, one of the requirements of the project is that all of these headers, subheaders, section names, etc. need to be editable by an admin. So my question is, where do I place the fields for these headers, subheaders, section names, etc? Do I have a separate VO for these things? Do I add fields into each of my other objects (userVO, planVO, etc.) to hold them?

What's the best design for this?

Thanks for your time!

[Jimmy Clark]

A good start would be to begin thinking about this application in tiers.
Sun's three-tier application model consisted of a Presentation tier, a Business tier and an Integration tier.
Typically the business component on the Business tier is designed separately from a GUI component which is part of the Presentation
tier. The GUI design is different that the Business component design. And the objects are not the same.

However, one of the requirements of the project is that all of these headers, subheaders,
section names, etc. need to be editable by an admin. So my question is, where do I place the
fields for these headers, subheaders, section names, etc? Do I have a separate VO for these things?
Do I add fields into each of my other objects (userVO, planVO, etc.) to hold them?

This is a Presentation tier requirement. Being able to modify header and section names in the GUI does
not sound like it is related to selling and managing life insurance plans. Keep in mind that objects are
only temporary. They live and die in-memory. So, in order for your GUI application to store these
modifiable section and header names, you will need a some sort of database to store them.

Again, this have very little to do with selling and managing life insurance plans. So this stuff certainly
does not belong in Business logic classes. This is for your Presentation object model. You should have a Business
object model that is independent from the GUI model. Once you get these two models figured out, they you start
design how they will work together.

If you stuff everyting into a single component, you will create a limited, hard-to-manage, unscaleable application.

[bryan nelson]

Thanks for the reply Jimmy.

We are separating things into different tiers, following an MVC2 architecture. Loosely, we have a data access layer (Oracle backend), a business delegate layer, and then a presentation layer.

So continuing on with my example and your reply, let me see if I understand. If I have a page that displays insurance plan information, but also has a requirement for editable header and section names could I do something like this:

I could have a PageContentVO which is the highest level object. It could have a few member fields as needed (i.e. pageTitle, sectionTitle, description, etc.) and then contain a generic list of other objects. These objects could be whatever is specific to the current page at hand. For example, if I'm trying to display insurance plan information then I would have a planVO inside my list of generic objects which I could then access on the display plan information page.

Would some sort of high level content object, with the ability to put page specific VOs in it work for this sort of thing?

[Jimmy Clark]

Sure it will work if you write the code correctly. Keep in mind that objects that contain business data for display in the GUI are not the "real" data objects from you business object model. These would be your Presentation layer data objects. And the classes from your Presentation object model can certainly have a combination of members, e.g. objects for your GUI labels and (Presentation) data objects containing insurance and user data.

The "real" data objects from the business object model should not have any GUI related stuff in their Class definitions.

[bryan nelson]

Ok. I understand what you are saying here, except I have one question.

The "real" data objects from the business object model should not have any GUI related stuff in their Class definitions.

The GUI related stuff that is in the class definitions for certain objects is actually coming from the database (since the requirement is to have editable display). So doesn't this requirement actually MAKE the GUI related stuff part of the business model in this case?

[Jimmy Clark]

The GUI related stuff that is in the class definitions for certain objects is actually coming from the database (since the requirement is to have editable display). So doesn't this requirement actually MAKE the GUI related stuff part of the business model in this case?

No, this does not make it a part of the business object model. The fact that some GUI data is
stored in a database does not make this data of these objects part of the business object model.

The values for GUI items come from the database. This data is used to create your Presentation tier GUI objects.

The purpose of your Business object model is for handling and implementing the business requirements.

The purpose of your Presentation object model is for providing a GUI for human users to interact
with the business application.

An application may have one or more databases. And an application's database(s) will typically have all sorts of
data that is not related to the business model. There can be performance data, database system data, administration data,
GUI data, etc.

The basis of your business object model are the aspects of the "sale" of the life insurance plans and the management of them. There will be
Presentation requirements and there will be Business requirements. There will be data requirements and performance requirements and security
requirements.

The point is that a good clean separation of these aspects and getting them to all work together nicely and efficiently is the core principle of
three-tier programming.

If you stuff everyting into a single component, you will create a limited, hard-to-manage, unscaleable application.

[bryan nelson]

Ok...I believe I see the difference that you are trying to get at here.

Thanks for your time! I appreciate it!