Vic,
2 each his own. I understand you view on EJB's and would apprechiate if you
keep that on your site and don't put that here.
We are using the EJB technology, but we also use DataAccessObjects (DAO),
the problem is that the data in the database is needed by both web clients
and other interfaces, XML/SOAP, and Java Swing Clients. We are using the
transformation process strickly on the web tier to eliminate some of the
manual coding within the Action class. We have JUnit tests for Form Beans
and ValueObjects (DTO) to remind us that when we update one we need to
update the other.
I'm just trying to give someone a peek at how we are planning on doing that.
If you have "been there done, done that, got the T-shirt" I would be
interested in hearing how you did the conversion from ValueObject (DTO) to
FormBean and return.
To the newbies, you don't want to sub-class a mixed type object within a
FormBean because of validation issues that Craig covered in prior posts. If
you want to do it automatically in a layered tier, I've described an
approach that we are trying. I by not way mean to imply this is the best
way or the only way. If you want an option there are plenty on this list to
provide it.
BTW, it's Friday.
>From: Struts Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Value object doubt !!!
>Date: Fri, 24 May 2002 08:10:02 -0700
>
>Subject: Re: Value object doubt !!!
>From: Vic C <[EMAIL PROTECTED]>
> ===
>Been there done that, got the T-Shirt. I used to do the same thing.
>And I found a simpler, better approach and have a tested production
>designs and fully functional sample code to show! Other designs are not
>showing fully functional code.
>I do project recovery for a living.
>For your consideration:
>
>Craig support light weight frameworks MVC I think and not forcing people
>to do things one way.(Are you using EJB? How are you addressing some of
>the issues in Software Reality EJB 101 that I and others found?)
>I hope to persuade Craig and others one way to look at a practical and
>simple and light weight alternative for model direction. I think it all
>stems from the old discussion of should form beans be a base class or an
>interface. (I think one of the reasons for Struts success is that it is
>light weight, simple and practical).
>
>The point of using a framework it to use it, and not build a framework.
>Analogy I use it you can wake up in the morning and drive a car, or go
>under the car and thinker with the combustion engine and the brakes. No
>need to mess with the technology. Use the force Luke, to make your
>project more productive.
>
>The larger the project the more the risk, so use Struts and don't do
>technology. ValueObject are just another bean. Transformation helper?
>You will get lost in the woods.
>
>Based on WebPIM from home page of StrutsPlus.com:
>Here is a repost on an alterntative design for your consideration,
>repost from news.strutsplus.com:
>
>[EMAIL PROTECTED]
> > Inline:
> >
> > > Rick Reumann wrote:
> > > I'm still new to trying to comprehend the various ways the Model
>layer
> > > can be implemented in a J2EE app, so I want to make sure I'm
> > > understanding a few things in relation to the webPIM sample app at
> > > www.basebeans.com.
> >
> > It is possible to use J2EE without EJB and it is possible and desirable
> > to use MVC with a less complexity. (No need for Business objects or
> > Value Objects in some cases, if they do nothing for you if only a DAO
> > would do). Doing things right means more scalability and faster to
> > develop with less effort.
> >
> > > 1) I was under the impression that you want to have your Data
>Transfer
> > > Objects (or Value Objects) to be as reusable as possible. It looks
> > > like in the case of the webPIM app that a typical bean (ie
>NameLstBean
> > > ) is tightly coupled with the table columns found in the DAO that
>the
> > > bean has as a member.
> >
> > Nope. This is a form bean; it should reflect the page properties, not
> > the physical data model. The bean is bound to the presentation. How the
> > physical DB does not matter to the public interface of the bean.
> > Idea here is that a requriment or html page would be the spec. You
>would
> > create a bean that follows it logicaly, with getters and setters
> > matching page properties.
> > (What confused you is the physical data model design, which a good
> > design follows the outputs and uses of the web app.)
> > So: Bean maps to the page logically. It hides the physical
> > implementation inside of it. Changes to the data model do affect the
> > implementation but not the "use" of the bean.
> > (Complex example: A bean getter could call another beans getter or
> > setter so you can have a bean that contains other beans for a complex
>page)
> >
> >
> > > The design seems to be: call a populate method
> > > on a particular bean which in turn will return a DAO to the bean
>that
> > > contains a cached rowset of the columns returned from the query.
>Then
> > > in order to get back say a First Name the bean will actually get a
> > > handle to the DAO stored in the bean and then call a method like
> > > nameLstDAO.getCRString("first_name"). (Forgive me Vic if I explained
> > > that all wrong ).
> >
> > You got it. Very simple delegation. You can unit test the beans CRUD,
> > and properties before you ever use it. And you can later make the
>beans
> > soapy.
> >
> >
> > > So my question is under this model it seems like if
> > > the underlying implementation changes, such as the column names in a
> > > table change, you end up having to fix all your beans plus all of
>your
> > > DAOs (as opposed to only having to change it one place if the DAOs
>are
> > > used to directly populate the beans).
> >
> > The public interface of the bean stays the same. So the users of the
> > data model layer are not affected. The whole point of separating the
> > data layer is that if it changes, the other 2 layers are unaffected.
> > You would only fix the implementation of the bean or the dao that has
> > the changed table. Of course once you have data in the DB, you would
> > with the changed db have to do data conversion, so changes to the
> > physical db are very rare.
> > More realistic is that you would add a column or maybe a table, and add
> > a bean or a bean property.
> >
> > > I'm guessing the reason for
> > > calling the db columns in the cached rowset might be so that the
>bean
> > > doesn't have to be populated in the DAO (although I'm not so sure
>why
> > > that would be so negative ).
> >
> > DAO does retrieve and store in a disconnected row set. It just holds it
> > there.
> >
> >
> > >
> > > 2) If each bean ( ie ListNmBean ) is responsible for populating
>itself
> > > where do you put SQL to populate a Collection of beans? ( I
>apologize
> > > Vic if you do this somewhere in the application that I haven't
>found).
> > > In your architecture it looks like the DAOs are only really called
> > > from within beans themselves, so in order to get a Collection of
> > > ListNmBeans would I need to create a CollectionOfNameBeans object
> > > which would call a DAO that would populate me with ListNmBeans?
> > >
> >
> > That's the beauty. Most retrievals are multi row. The DAO has the (
> > disconnected ) rowset. The rowset is your "collection" of rows. (No
>need
> > for a collection, when the rowset has the full metadata and is
> > disconnected) It contains multiple rows (no need for multiple beans and
> > garbage collection load). The Bean has iterate. It iterates the DAO ('s
> > rowset). Multi row retrievals like nameLst or multi row updates are a
> > synch. and easily unit testable at the bean level (with not web app
> > needed to unit test, the whole point of unit test it to test one
>thing).
> >
> >
> > > 3) Using an architecture such as the webPIM app it looks like you
> > > would only need one type of bean to hold your main object's fields.
> > > For example I'd only need an EmployeeBean, and wouldn't need an
> > > EmployeeBean plus a Data Transfer Object EmployeeBean.
> >
> > Yes. KISS
> >
> > > In the webPIM
> > > app am I correct in assuming objects such as the NameLstBean act as
>a
> > > Data Transfer Object or Value Object and also acts as what I hear
> > > other's mention as an Entity or Session bean?
> >
> > Value Object and Data Transfer Object and Business Objects are just
> > Beans. The less you do, the faster you write it, the less code, the
>less
> > has to go trough CPU, the less code, the less bugs, less GC. Benefits
> > pile on. Plus easier to debug.
> >
> > EJBs (and design patterns to try to make them palatable) is something I
> > r USED TO USE, but I do not use them anymore (in fact my new and
> > existing clients that might have them are having the EJBs removed). You
> > do not need EJB to do J2EE. Look at some of my post about software
> > reality . com and the first 101 reasons not to use EJB. EJB only work
>in
> > lab conditions and most organizations remove them eventually. EJB is a
> > technology in search of a problem.
> >
> >
> > >
> > > 4) I take it each bean would contain all different overloaded
>populate
> > > methods for different ways you would want to return an Employee? For
> > > example "populate( int employeeId )" or "populate( String firstName,
> > > String Last Name )" ?
> >
> > Yup.
> > Do you see how simple this design is? (especially compare to pet store
> > type designs)
> > A bean and a DAO (DAO with a "collection" of rows")
> > It is always better to look at a real application and code.
> > Most clients can be talked into removing EJB and other objects they do
> > not use, if it is helpful to them.
> > Simple = flexible = less effort.
> >
> > Actually, anyone can build a web app. But a software engineer can help
> > you use less resources and effort and make it more scalable and
> > maintainable.
> >
> > Hth, V.
> >
> >>
> >>
> >> Thanks for any help with this.
> >>
>
>
>
>
>
>STEVE WILKINSON wrote:
> > Given the comments from Craig on not using Value Objects as form beans
> > our project is taking the following approach.
> >
> > We are creating a "helper" class to transform our ValueObject (Data
> > Transfer Object as we call it) into a form bean (Strings, Boolean, and
> > boolean types only) and the reverse. I started this effort by looking
> > at the code within the beanutil package that is part of commons.
> > Unfortunately, object composition is not supported (User object contains
> > an Address object) within the commons code base. So, I've taken to
> > writing our own transformation helper and take advantage reflection and
> > the convertion utilities provided in the commons package. Granted this
> > is not an approach that a small project should take, but ours is a
> > fairly large project and we wanted to create a "Helper class" to assist
> > in transforming the data between tiers. The idea is that each interface
> > (Struts being the HTTP interface) will have it's own helper class to
> > assist in this. I will reduce a little coding, but provide easy
> > tranformation of the data between tiers.
> >
> > Currently, the transformation helper class is dependent on our own
> > package structure. :-( I'm hoping to be able to refactor this so that
> > it's configurable like the ConvertUtils does and I'll offer it up if
> > people are
> > interested. Also, since we are only prototyping right now, I don't
> > provide support for Collections, but I do provide support for Object
> > Array types (e.g. User[] user). The intent is to provide Collection
> > support in the future, but I must utilize a "type safe" collection that
> > is initalized with "type" or it's class that will be stored at
> > initialization in the target object so the transformation utility knows
> > what class to create when transforming an object from one collection to
> > the other. We are using the same names for our attributes and classes,
> > it's just different data types. The DTO (VO) contains mixed type,
> > java.sql.Date, java.lang.Float, etc. The FormBean
> > currently only has String, Boolean and boolean types.
> >
> > Hope this helps give an idea on another approach.
> >
> > Steve
> >
> >
> >
> >> From: Ted Husted <[EMAIL PROTECTED]>
> >> Reply-To: [EMAIL PROTECTED]
> >> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >> Subject: Re: Value object doubt !!!
> >> Date: Fri, 24 May 2002 08:47:27 -0400
> >>
> >> The best stategy will depend on what else is going on with your
> >> application.
> >>
> >> The ActionForm is really part of the control layer and so can interact
> >> with objects on both the presentation and business layers.
> >>
> >> A generally useful approach is to put a factory method on the
>ActionForm
> >> that returns your value object.
> >>
> >> This neatly encapsulates the data transfer. All the Action has to do is
> >> call the method and pass along the result.
> >>
> >> Which I guess is your #2.
> >>
> >> -- Ted Husted, Husted dot Com, Fairport NY US
> >> -- Developing Java Web Applications with Struts
> >> -- Tel: +1 585 737-3463
> >> -- Web: http://husted.com/about/services
> >>
> >>
> >> Radhika Nadkarni wrote:
> >> >
> >> > hi,
> >> > Im having an action Form. Im using Value object for data conversions.
> >> > Now my problem is i have two scenarios for implementing the same : -
> >> > 1) Value object will be separate
> >> > 2) Value object will be composed within the Form Bean.
> >> > Can anyone tell me which is the best strategy out of the two ?
> >> >
> >> > _________________________________________________________________
> >> > Get your FREE download of MSN Explorer at
> >> http://explorer.msn.com/intl.asp.
> >> >
> >> > --
> >> > To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> > For additional commands, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >>
> >
> >
> > _________________________________________________________________
> > Chat with friends online, try MSN Messenger: http://messenger.msn.com
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
