Copying of properties vs. nested VO

[Michael Jouravlev <jm...@gmail.com>]

Anyone in the mood to kick the dead horse again? I decided to compare
two approaches to use/update data from Struts. I am obviously biased
towards nested VO/BO, so maybe I left something out.

[I] Property copying

This one seems to be the default and "officially endorsed" Struts practice.

1) Create/Load data.
Workflow:
* To use existing data it is loaded from database into BO/VO, then
BO/VO properties are copied to action form.
* To create new data nothing special is performed, action form is just
cleaned if it has session scope.

Notes:
* BO/VO usually has strongly typed properties.
* Validation is usually performed in the action form.
* Intermediate data is flying around action form/request/response.
* Because of double data copying (from database to BO/VO, then from
BO/VO to action form) it is tempting to avoid BO/VO altogether or to
make it as dumb as possible. Thus, this approach usually uses
struct-type VO instead of behavioral BO.

2) Modify data

Current data is kept in the action form, usually having request scope.

Notes:
* Request-scoped action forms do not allow to use two-phase request processing

3) Store data

Workflow:
* Data is validated in the action form first, then copied to BO/VO
* BO/VO validates business rules
* BO/VO is stored in the database

Notes:
* Business rules are validated after data is copied from action form
to BO/VO; inefficient.
* In this approach BO/VO is usually treated like a persistent object
(EJB-style), that is modifications to BO/VO are immediately reflected
in database.


[II] Using nested BO/VO

1) Create/Load data.
Workflow:
* To use existing data it is loaded from database into BO/VO; this
BO/VO is detached from database, that is all changes to it do not
affect persistent data.
* To enter new data a new instance of BO/VO is created; it is detached
as well. ID/PK can be generated on this stage or is created on "store"
stage.
* BO/VO is kept in the session, or stored as nested object in the
action form, which has session scope.

Notes:
* BO/VO usually has string properties or double-type properties:
string/strong. Another choice is to define action form's setters as
string, and to set BO data from within them.
* Validation is performed partly by the BO/VO, and partly by the action form.
* Intermediate data is kept in the BO/VO; transient data is kept in
the action form.
* This approach better supports OO model; enforces usage of a real BO
with behavioral methods.

2) Modify data

Current data is kept in the BO nested in the action form; action form
has session scope. HTML form can either use/set nested properties
directly, or use action form's setters/getters, which convert data and
set it in the nested BO.

3) Store data

Workflow:
* Transient data is validated by the action form.
* Business data is validated by nested BO
* BO/VO is stored in the database

Two major questions is where to perform validation and type
conversion. One opinion is to perform validation and type conversion
in an action form, and to have strongly typed VOs. Another is to have
string- or string/strong properties for BO, which may provide better
flexibility for different web frameworks and clients (for web service,
WML, VoiceXML, non-Struts - most rules are in one place despite of
different UI).

Transient property may be stored in the BO to have all validation rules in BO.

Did I miss something or got something wrong?

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

[OT] Re: Copying of properties vs. nested VO

[Dave Newton <ne...@pingsite.com>]

Adam Hardy wrote:

> Not all users can think like geeks!

And the (probably more important!) corollary: Most geeks can't think 
like users.

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Copying of properties vs. nested VO

[Michael Jouravlev <jm...@gmail.com>]

On 7/18/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Michael Jouravlev on 18/07/05 20:52, wrote:
> > I am not convinced that UI should be *that* different from domain
> > model. Do you have examples?
> 
> I'm not sure that I can conjure up something convincing (being a techie
> myself!) because you have to be fairly good at useability implementation
> to be able to evangelise about it. However here goes with an example
> from a project I worked on for a travel company (one of many examples).
> 
> We were given UI mock-ups by the business analyst and one form was for
> contact details, including 3 telephone numbers (office, fax & mobile)
> each with 2 dropdowns (international dialling code and area dialling
> code). The business analyst had worked closely with the Data Architect
> without the benefit of an application designer.
> 
> The dropdowns affected useability because each choice of international
> dialling code forced a javascript event-driven page reload to fetch the
> corresponding area code dropdown. When javascript was declared optional,
> we then had to incorporate buttons to allow the user to call up the new
> dropdown content.
> 
> We started off having Hibernate disconnected DTOs nested right there in
> the actionForm - the model was the address DTO, which had a child phone
> number, which had a parent area code and a grandparent international
> dialling code.
> 
> In terms of /both/ useability /and/ implementation, it was a joke, yet
> it had to appear in multiple places on the website.
> 
> I wanted to change it to allow the user to type in the whole number in
> one field and then to write a validation algorithm to establish the
> international and area dialling codes, and then to redisplay the 3
> fields for edit, only if the algorithm failed.
> 
> However the project was underfunded and I didn't get time :(

You call this a good UI? Man, this is horrible. I don't blame you,
because you wanted to do the right thing, combining stuff together.
The idiots who think that choosing from endless comboboxes is easier
that to type a phone or a date or address directly, should be
procecuted by prohibiting them to do UI design forever. I hate this
design. Not as a developer, but as a user. Yuck.

Anyway, even with this design nothing prevents to use actual BO in the
session-scoped form, and to have three "transient" values outside the
BO. BO does not know or care how the phone number is combined. When
request is submitted, the actual phone is built from parts somewhere
in validate() or in the Action class. Then this real phone is
validated. If it is incorrect, page is redisplayed. The downside is
that validation can detect that area code is wrong, but it cannot tell
UI layer to correlate the error message to a particular combobox. On
the other hand, the whole point of comboboxes was to prevent errors
with area codes.

With nested BO you would have detached address with real phones, and
you would have (one "transient" "local phone" field and two
comboboxes) * times three. It would still work. I guess, indexed
properties could be used. I think, it is still better than copying
properties. You have business rules right there, and there is no need
to copy most of the properties. UI that you described is still close
to domain model: location(s) and corresponding phone numbers (cell
phone belongs to a virtual location with no physical address).

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Copying of properties vs. nested VO

[Adam Hardy <ah...@cyberspaceroad.com>]

Michael Jouravlev on 18/07/05 20:52, wrote:
> On 7/18/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> 
>>While the business domain is normally modelled using OO techniques, the
>>view or user interface should be modelled using human behaviour analysis
>>techniques that produce the best interface for users to get their work
>>done efficiently, reflecting their mental model of what is going on.
> 
> ...
> 
>>If you do [the business/UI shortcut] everywhere, you run the risk 
>>of forcing your users to learn the business domain OO model
>>which might be a huge leap away from their own mental model.
> 
> 
> While I may agree that business model may differ from UI model, I
> cannot agree with the idea that they *should* be different. The first
> principle of OOP is that program objects reflect actual life objects.
> Department, employee, order, order items, etc. These are things that
> people work with, and these should be modeled by domain model.

> For example, we have department and employees. Or an order and order
> items. I think everyone would model it as Order-1:M-Item. What does a
> user work with? Same order and order items. What does a user expect to
> see? An order and items, corresponding to it.
> 
> Of course, there are reference tables/objects, there are additional
> tables to ensure M:M relationship, there is a lot of plumbing behind.
> But a user does not work with plubming objects, unless it is a
> combobox with options.
> 
> For example, Outlook Express. We have Folders with typed items like
> emails or news or forums. For each forum item there is a list of
> messages. For messages there is view preferences, sort order, and
> such. So, Folders and messages are definetely business objects. View
> preferences... that depends, but considering that OE's data model is
> specifically built for user interaction, view preferences can be
> stored along with each forum/message list as business object.
> 
> I am not convinced that UI should be *that* different from domain
> model. Do you have examples?

I'm not sure that I can conjure up something convincing (being a techie 
myself!) because you have to be fairly good at useability implementation 
to be able to evangelise about it. However here goes with an example 
from a project I worked on for a travel company (one of many examples).

We were given UI mock-ups by the business analyst and one form was for 
contact details, including 3 telephone numbers (office, fax & mobile) 
each with 2 dropdowns (international dialling code and area dialling 
code). The business analyst had worked closely with the Data Architect 
without the benefit of an application designer.

The dropdowns affected useability because each choice of international 
dialling code forced a javascript event-driven page reload to fetch the 
corresponding area code dropdown. When javascript was declared optional, 
we then had to incorporate buttons to allow the user to call up the new 
dropdown content.

We started off having Hibernate disconnected DTOs nested right there in 
the actionForm - the model was the address DTO, which had a child phone 
number, which had a parent area code and a grandparent international 
dialling code.

In terms of /both/ useability /and/ implementation, it was a joke, yet 
it had to appear in multiple places on the website.

I wanted to change it to allow the user to type in the whole number in 
one field and then to write a validation algorithm to establish the 
international and area dialling codes, and then to redisplay the 3 
fields for edit, only if the algorithm failed.

However the project was underfunded and I didn't get time :(





---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Copying of properties vs. nested VO

[netsql <ne...@roomity.com>]

Michael Jouravlev wrote:

> 
> I am not convinced that UI should be *that* different from domain
> model.


+1.

Example: You make a html mock up an go to contract, then do ren *.html 
to *.jsp for prototype.
Beased on your approved prototype your most senior desigs a domain model!

Domain Model is more physical vs model model is more logical view. Ex: 
Customer has mutiple addresses in physical, but in logical it's just 
customer.

.V


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Copying of properties vs. nested VO

[Michael Jouravlev <jm...@gmail.com>]

On 7/18/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> While the business domain is normally modelled using OO techniques, the
> view or user interface should be modelled using human behaviour analysis
> techniques that produce the best interface for users to get their work
> done efficiently, reflecting their mental model of what is going on.
...
> If you do [the business/UI shortcut] everywhere, you run the risk 
> of forcing your users to learn the business domain OO model
> which might be a huge leap away from their own mental model.

While I may agree that business model may differ from UI model, I
cannot agree with the idea that they *should* be different. The first
principle of OOP is that program objects reflect actual life objects.
Department, employee, order, order items, etc. These are things that
people work with, and these should be modeled by domain model.

For example, we have department and employees. Or an order and order
items. I think everyone would model it as Order-1:M-Item. What does a
user work with? Same order and order items. What does a user expect to
see? An order and items, corresponding to it.

Of course, there are reference tables/objects, there are additional
tables to ensure M:M relationship, there is a lot of plumbing behind.
But a user does not work with plubming objects, unless it is a
combobox with options.

For example, Outlook Express. We have Folders with typed items like
emails or news or forums. For each forum item there is a list of
messages. For messages there is view preferences, sort order, and
such. So, Folders and messages are definetely business objects. View
preferences... that depends, but considering that OE's data model is
specifically built for user interaction, view preferences can be
stored along with each forum/message list as business object.

I am not convinced that UI should be *that* different from domain
model. Do you have examples?

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Copying of properties vs. nested VO

[Adam Hardy <ah...@cyberspaceroad.com>]

Having a VO/BO with string- & strong-property getters and setters is 
IMHO a short cut through the UI / business domain interface.

While the business domain is normally modelled using OO techniques, the 
view or user interface should be modelled using human behaviour analysis 
techniques that produce the best interface for users to get their work 
done efficiently, reflecting their mental model of what is going on. If 
you want a good app, you really should do some decent user interface 
design work on it.

There would be an interface where business domain VOs / BOs are mapped 
onto user interface VOs via code.

Your short-cut can cut through this, but if you do it everywhere, you 
run the risk of forcing your users to learn the business domain OO model 
which might be a huge leap away from their own mental model. That would 
lead to an inefficient user interface where the users take much longer 
to get up to speed, if they manage it at all. Not all users can think 
like geeks!

Adam



Michael Jouravlev on 18/07/05 19:02, wrote:
> Anyone in the mood to kick the dead horse again? I decided to compare
> two approaches to use/update data from Struts. I am obviously biased
> towards nested VO/BO, so maybe I left something out.
> 
> [I] Property copying
> 
> This one seems to be the default and "officially endorsed" Struts practice.
> 
> 1) Create/Load data.
> Workflow:
> * To use existing data it is loaded from database into BO/VO, then
> BO/VO properties are copied to action form.
> * To create new data nothing special is performed, action form is just
> cleaned if it has session scope.
> 
> Notes:
> * BO/VO usually has strongly typed properties.
> * Validation is usually performed in the action form.
> * Intermediate data is flying around action form/request/response.
> * Because of double data copying (from database to BO/VO, then from
> BO/VO to action form) it is tempting to avoid BO/VO altogether or to
> make it as dumb as possible. Thus, this approach usually uses
> struct-type VO instead of behavioral BO.
> 
> 2) Modify data
> 
> Current data is kept in the action form, usually having request scope.
> 
> Notes:
> * Request-scoped action forms do not allow to use two-phase request processing
> 
> 3) Store data
> 
> Workflow:
> * Data is validated in the action form first, then copied to BO/VO
> * BO/VO validates business rules
> * BO/VO is stored in the database
> 
> Notes:
> * Business rules are validated after data is copied from action form
> to BO/VO; inefficient.
> * In this approach BO/VO is usually treated like a persistent object
> (EJB-style), that is modifications to BO/VO are immediately reflected
> in database.
> 
> 
> [II] Using nested BO/VO
> 
> 1) Create/Load data.
> Workflow:
> * To use existing data it is loaded from database into BO/VO; this
> BO/VO is detached from database, that is all changes to it do not
> affect persistent data.
> * To enter new data a new instance of BO/VO is created; it is detached
> as well. ID/PK can be generated on this stage or is created on "store"
> stage.
> * BO/VO is kept in the session, or stored as nested object in the
> action form, which has session scope.
> 
> Notes:
> * BO/VO usually has string properties or double-type properties:
> string/strong. Another choice is to define action form's setters as
> string, and to set BO data from within them.
> * Validation is performed partly by the BO/VO, and partly by the action form.
> * Intermediate data is kept in the BO/VO; transient data is kept in
> the action form.
> * This approach better supports OO model; enforces usage of a real BO
> with behavioral methods.
> 
> 2) Modify data
> 
> Current data is kept in the BO nested in the action form; action form
> has session scope. HTML form can either use/set nested properties
> directly, or use action form's setters/getters, which convert data and
> set it in the nested BO.
> 
> 3) Store data
> 
> Workflow:
> * Transient data is validated by the action form.
> * Business data is validated by nested BO
> * BO/VO is stored in the database
> 
> Two major questions is where to perform validation and type
> conversion. One opinion is to perform validation and type conversion
> in an action form, and to have strongly typed VOs. Another is to have
> string- or string/strong properties for BO, which may provide better
> flexibility for different web frameworks and clients (for web service,
> WML, VoiceXML, non-Struts - most rules are in one place despite of
> different UI).
> 
> Transient property may be stored in the BO to have all validation rules in BO.
> 
> Did I miss something or got something wrong?
> 
> Michael.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org