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]>
