Personally, for a small project (like YOU are the dev team), if it works, great. You can always refactor. But best practices would probably say, do not let your lower tiers depend on the upper ones. So, if your persistent or domain object extends/implements a view object, you've already broken that rule. I think this is most important in middle to larger projects with a high degree of risk that needs to be controlled.
I would suggest a proxy or some type of view object that contains a domain object and proxies the calls. This way, the domain is not changed if the current view is changed. And, the view's proxy is the only thing that changes if the domain model changes. Does that make sense? - gene > ATTACHMENT part 15 message/rfc822 > From: "Bailey, Shane C." <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Is it always bad to pass middle tier object > to view? > Date: Mon, 9 Jun 2003 13:53:40 -0400 > > > > I am thinking if you have a User object similar to: > > > > public class User extends > ThirdPartyObjSayForStorageReasons implements > UserAsSeenByView > > { > > ... > > } > > > > > > and you are using it in the view layer as > UserAsSeenByView and you didn't > have to add > > any extra methods to implement the view then it > seems much more efficient > than using reflection > > or calling a bunch of getters and setters to simple > pass the object along. > > > > > At any given time in the future if you didn't like > that way, you could > actually make UserAsSeenByView > > an instantiable (doesn't sound correct?) class, then > in your action fill it > (BeanUtils), and pass it back. > > There would be not much difference. > > > > Is this only a big deal if using RMI or something > and passing a possibly > much heavier object than > > need be over the remote connection? __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]