Hi, > Option 1: You have a VO containing a constructor with a billion > parameters. > > Problem: It looks horrible; it is a bitch to write against and you > potentially loose valuable compile-time checking (esp. if a lot of the > parameters have the same type)
Let xdoclet handle it for you. No coding in your side. > Option 2: You have a parameterless constructor and a billion > accessors/mutators (or public fields depending on your religous > persuasion). > > Problem: You immediately have the possibility of superficially correct VOs > which are only partially created. i.e. The developer has to remember to > call > all required setters - it is not compile-time enforced. (If you are of the > private field persuasion, you also have the overhead of writing (or > getting > something to write for you) a billion getters and setters) Let xdoclet handle it for you. No coding in your side. > Does anyone have the winning Option 5? Well, whatever option 5 could be, the only thing I can add to this thread is that imho indeed value objects are bad, except for listing purposes. VO is just a workaround for the heavy/container-dependent EJBs. You can't pass EJBs to remote clients, right? So we invented VO. In most cases you really just want to show a list of objects to user, then user click on one of these and you do something on the detail. For listing purposes VO is great, you don't move a whole graph of objects around and it acts like a very lightweight stub for the real bean. For any significant operation on an object, it's just ridiculous to rely on VOs imho. Now, how can you pass EJBs to remote clients? Well, I solved this problem but not using entity bean! I use simple javabeans, hidden behind session facades. There's no significant logic in entities, all in session fa�ade. Imho though that sometimes sounds like bad according to OO guidelines but imho it's absolutely ok, it's like separating the 'business aspect' (or whatever in detail aspect) of a service to a separate handler object. PS: More and more people will get sick of all this VO stuff, when webservices/soap becomes more popular. It's a new paradigm with completely different architectural requirement than the ol' browser based stuff. You just can't handle all those passing VO graphs to client and vice versa! > Rich Cheers, Ara. ==========================================================================To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
