Subject: Re: Value object doubt !!! From: Vic C <[EMAIL PROTECTED]> === Don't kill the messenger. That's what some of this is about. I do not know of any contradictions documents or comments and my and other consultants experience is inline with this. See point 95, I think that is why there are a few vocal sales people who say the emperor IS wearing some clothing. This is why I did what is says on page 4, 2nd sentence. The working full realistic example webPIM is Struts specific. However the choice I did to implement the dao (DAO has nothing to do with Struts. Struts only defines the form Bean and MVC ) is what is says on page 4 2nd sentence.
JDO got recently delayed or pulled. You cant do XML joins (as JDO implies), and have some of the same EQL issues. On news.strutsplus.com there is a newsgroup Castor a leading JDO implementation. I wish there was a better place than Struts MVC to talk about the M at length. Anyway, my implementation works well at several client's production sites and ... I am the only one to share a public realistic full example with tiles, validation, master detail, CRUD, model, navigation, options, formatting, etc. which I think kind of makes me a bit of a target. Some day there will be a better practice to CRUD Master/Detail applications that are better than webPIM. My goal was webPIM as a Struts MVC example, but by separating the DAO outside of the bean, people can implement the DAO anyway they chose, and not follow my design. Or they can refractor and improved DAO and not break the bean. They only good choice, for people that hire me to advise them or recover their project, is to roll your own beans. I had to show a working realistic M in webPIM and did so. Nice thing about open standards is that any potential weakens is publicized and criticized and a road to improvements is open, by those wiling to implement it. When MS has a weakness, it is "forbade to criticize the HQ". Cathedral and the Bazaar book shows why open standard will defeat the "Cathedral approach. Vic Michael Delamere wrote: > Hi, > > I´ve just read the "EJB_101Damnations.pdf". Could somebody lead me to an > article that may contradict the 101Damnations pdf. If the specified pdf is > overall correct, what are the alternatives? JDO?? > > Could someone please clarify me on this issue. > > Thanks, > > Michael > > > ----- Original Message ----- > From: "Struts Newsgroup" <@[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, May 24, 2002 7:25 PM > Subject: Re: Value object doubt !!! > > > >>Subject: Re: Value object doubt !!! >>From: Vic C <[EMAIL PROTECTED]> >> === >>Fat fingered "do not look at" >>http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf >> >> >>Vic Cekvenich wrote: >> >>>STEVE WILKINSON wrote: >>>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. >>> >>> Should I say do not look at >>> http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ? >>> Not sure how to respond to this. EJB's is something I used in the >>> model; and now I don't. You don't think people should be exposed as >>> to why that is? Certainly new users and new managers should be aware >>> that you can do MVC and J2EE without EJB and at least some feel that >>> this is better. My guess is EJBs are going to go the way of the >>> client side Java, that is to say, they will not be used. I predict >>> that the silent majority used to use EJB's and don't use EJB anymore >>> and very soon that will be conventional wisdom not to use EJB. I >>> would say people that argue EJB is good lose some credibility with >>> me (and you could say people that argue EJB are not good lose >>> credibility with you. 2 each his own) I do ask for comments on >>> http://www.bad-managers.com/Features/ejb/index.shtml here or at >>> mvc-programmers. >>> >>> >>>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. >>> >>> :-\ , You can look at a post in the mvc-programmers news group on >>> how it is benefitial to have a single model beans for use by SOAP, >>> Swing, etc. >>> >>> >>>I'm just trying to give someone a peek at how we are planning on doing >>>that. >>> >>> >>> It looked like a question. >>> >>> >>> >>> >>>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. >>> >>> I have a post of the code on the strutsplus.com home page. Again, >>> feel free to comment on the implemented design. >>> >>> >>>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. >>> >>> I just need not to look at this list on Fridays. ;-) >>> Vic >>> >>> >>> >>>> >>>>>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]> >>>> >>> >>> >>>-- >>>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]> > > > > -- > 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]>
