You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <st...@reumann.net> on 2004/03/29 18:22:36 UTC
best practice question for certain VO/DTO fields?
Curious about the different ways you guys handle this..
For simplicity, imagine you are needing to return a List of
Employee objects. Each Employee belongs to a department.
What I debate about is how to handle the creation of the
Employee Value Object in relation to "department." From a
business perspective I really only need to worry about an int or
Integer representing "departmentID", yet for display purposes
I'll often need to display "dpeartmentName." There seems to be
several ways to handle this...
1) Store a Department object (id, name) as a field inside of
Employee. This is nice from an OO perpsective, but can be a bit
more difficult to handle depending on the persistence mechanism
of choice. I tend to think this approach can create a bit of
unnecessary overhead.
2) Simply store another field in EmployeeVO as String
departmentName. I seem to end up doing this because it's simple,
but it just doesn't 'feel' right. The EmployeeVO only really
needs to know what departmentID it should have. The
departmentName is only important for display purposes.
3) Provide some way for your display to figure out the
departmentName based on a given departmentId (JSP tag, map
lookup, whatever). I don't really like this approach because if
the values can change (in this case Departments), it requires a
db lookup any time you want to get a departmentName (unless you
create some guaranteed way to have a cache updated). Plus this
is only an example and it's just one field, but potentially your
application can have a bunch of similiar things to deal with -
do you really want to have to create a bunch of tags or maps to
deal with this?
4) Return a List of Department objects and in each of those pull
out a List of Employees. Awkward to work with (some gymnastics
to get a complete employees display back ordered correctly).
Also department could contain tons of fields other than List or
Collection of Employees. Do we really want a whole bunch of
Department objects back just to get our employees? This also
a potential problem in option 1 above as well. Even if all the
fields of Department aren't populated, it still seems ugly
having this big object as part of an Employee.
Thanks for ideas on how you guys handle this.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: best practice question for certain VO/DTO fields?
Posted by Rick Reumann <st...@reumann.net>.
On Mon, Mar 29, 2004 at 11:44:49AM -0500, Alan Weissman wrote:
> So for your specific problem, I would go with #1 and put a department
> object on an Employee. If you give me more information on what your
> schema and use cases are, I can help you with the persistence layer.
Well, I was just proposing the question in general and using
Employee/Department as an example. I guess as a compromise
approach, I'd nest Department in Employee and for a
"getEmployees" query I simply wouldn't populate everything
that a Department could possibly contain. This approach
creates some awkwardness though since now you'd also need a
specialized "department query" that would only pertain to
when you are getting back a List of employees, otherwise the
common approach seems to be just populate everything in
Department and jam into each Employee object. (A lot of
extra overhead imo for say all you might want is
departmentName out of the object).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: best practice question for certain VO/DTO fields?
Posted by Rick Reumann <st...@reumann.net>.
On Mon, Mar 29, 2004 at 09:09:24AM -0800, Hubert Rabago wrote:
> There's one custom tag which also accepts a key and can
> optionally accept the name of the object's attribute to display. So I can do
> <my:lookup list="departments" key="${employee.departmentId}"
> property="name"/> to display the department name for the employee, and in
> almost all cases I don't have to create a separate tag.
This is exactly the approach I'm going to use for a demo.
Thanks.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: best practice question for certain VO/DTO fields?
Posted by Hubert Rabago <ja...@yahoo.com>.
Hi Rick,
I do #1 and #3 depending on the nature of the field. It keeps the objects
separate.
For objects that are pretty dynamic or don't come from a set list, I'd do #1.
My DTO's know whether a field has been populated or not and throws an error
when the path taken by the request didn�t populate it.
I do a #3 for a more generic "lookup" type object where the values don't
change often (or at all), such as "position" of an "employee" (where a
"position" might have attributes such as pay level, parking area, benefits
package, etc - hard to think of another example right now). The employee's
position might change, but the pay level, parking aread, and benefits package
of any given position won't change much. For such objects, I have a lookup
system that's pretty generic which I use to look them up based on keys (such
as "position" or "departmentId"). It manages several lists, each of which is
individually configured in an XML file and has settings for how often they're
reset or reloaded based on time and/or number of reads. Some lists reset
everyday, some after 100 reads, some after 1 day or 10000 reads whichever
comes first. There's one custom tag which also accepts a key and can
optionally accept the name of the object's attribute to display. So I can do
<my:lookup list="departments" key="${employee.departmentId}"
property="name"/> to display the department name for the employee, and in
almost all cases I don't have to create a separate tag. (Haven't really had
to yet, though I don't discount the possibility. In such a case it wouldn't
be difficult since it'll use the same lookup management object.)
Hubert
--- Rick Reumann <st...@reumann.net> wrote:
> Curious about the different ways you guys handle this..
>
> For simplicity, imagine you are needing to return a List of
> Employee objects. Each Employee belongs to a department.
>
> What I debate about is how to handle the creation of the
> Employee Value Object in relation to "department." From a
> business perspective I really only need to worry about an int or
> Integer representing "departmentID", yet for display purposes
> I'll often need to display "dpeartmentName." There seems to be
> several ways to handle this...
>
> 1) Store a Department object (id, name) as a field inside of
> Employee. This is nice from an OO perpsective, but can be a bit
> more difficult to handle depending on the persistence mechanism
> of choice. I tend to think this approach can create a bit of
> unnecessary overhead.
>
> 2) Simply store another field in EmployeeVO as String
> departmentName. I seem to end up doing this because it's simple,
> but it just doesn't 'feel' right. The EmployeeVO only really
> needs to know what departmentID it should have. The
> departmentName is only important for display purposes.
>
> 3) Provide some way for your display to figure out the
> departmentName based on a given departmentId (JSP tag, map
> lookup, whatever). I don't really like this approach because if
> the values can change (in this case Departments), it requires a
> db lookup any time you want to get a departmentName (unless you
> create some guaranteed way to have a cache updated). Plus this
> is only an example and it's just one field, but potentially your
> application can have a bunch of similiar things to deal with -
> do you really want to have to create a bunch of tags or maps to
> deal with this?
>
> 4) Return a List of Department objects and in each of those pull
> out a List of Employees. Awkward to work with (some gymnastics
> to get a complete employees display back ordered correctly).
> Also department could contain tons of fields other than List or
> Collection of Employees. Do we really want a whole bunch of
> Department objects back just to get our employees? This also
> a potential problem in option 1 above as well. Even if all the
> fields of Department aren't populated, it still seems ugly
> having this big object as part of an Employee.
>
> Thanks for ideas on how you guys handle this.
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: best practice question for certain VO/DTO fields?
Posted by Alan Weissman <aw...@nyc.yamaha.com>.
Hey Rick -
I use a combination of #1 and #2. NEVER #3 or #4.
#1 happens a lot especially when 'stars' appear in your schema, ie where
you start finding that you are pulling everything out by EmployeeId. A
persistence mechanism isn't an issue for me as I have always ended up
building my own - none of the prebuilt ones seem to provide enough
flexibility.
#2 happens when you have just one field that you need to bring into a VO
from a junction or lookup table adjacent to your table. For instance,
if an employee has a type table, and that type has a label, I might just
add the type to the employee object.
So for your specific problem, I would go with #1 and put a department
object on an Employee. If you give me more information on what your
schema and use cases are, I can help you with the persistence layer.
HTH,
Alan
-----Original Message-----
From: Rick Reumann [mailto:struttin@reumann.net]
Sent: Monday, March 29, 2004 11:23 AM
To: Struts Users Mailing List
Subject: best practice question for certain VO/DTO fields?
Curious about the different ways you guys handle this..
For simplicity, imagine you are needing to return a List of
Employee objects. Each Employee belongs to a department.
What I debate about is how to handle the creation of the
Employee Value Object in relation to "department." From a
business perspective I really only need to worry about an int or
Integer representing "departmentID", yet for display purposes
I'll often need to display "dpeartmentName." There seems to be
several ways to handle this...
1) Store a Department object (id, name) as a field inside of
Employee. This is nice from an OO perpsective, but can be a bit
more difficult to handle depending on the persistence mechanism
of choice. I tend to think this approach can create a bit of
unnecessary overhead.
2) Simply store another field in EmployeeVO as String
departmentName. I seem to end up doing this because it's simple,
but it just doesn't 'feel' right. The EmployeeVO only really
needs to know what departmentID it should have. The
departmentName is only important for display purposes.
3) Provide some way for your display to figure out the
departmentName based on a given departmentId (JSP tag, map
lookup, whatever). I don't really like this approach because if
the values can change (in this case Departments), it requires a
db lookup any time you want to get a departmentName (unless you
create some guaranteed way to have a cache updated). Plus this
is only an example and it's just one field, but potentially your
application can have a bunch of similiar things to deal with -
do you really want to have to create a bunch of tags or maps to
deal with this?
4) Return a List of Department objects and in each of those pull
out a List of Employees. Awkward to work with (some gymnastics
to get a complete employees display back ordered correctly).
Also department could contain tons of fields other than List or
Collection of Employees. Do we really want a whole bunch of
Department objects back just to get our employees? This also
a potential problem in option 1 above as well. Even if all the
fields of Department aren't populated, it still seems ugly
having this big object as part of an Employee.
Thanks for ideas on how you guys handle this.
--
Rick
---------------------------------------------------------------------
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