Quite frankly, it baffles me when people want to use form beans as the model. Doing this couples the model to the view in wholly undesirable ways.
For instance, what happens when the UI designer moves things around in the pages in such a way that the mappings between UI elements and pages (and thus form beans) change? It seems that you'd have to change the model now, just because the UI designer made some tweaks to the view. This kind of coupling is entirely unacceptable in anything other than trivial apps. Another example: What happens when management comes back and says that now you need to build a WebStart version of the app? Sure, you could drag around the Struts jar (and the servlet jar, etc, etc) just so that you can keep using form beans. But now you have to explain the use of Struts to the Swing engineers who are brought on to the project. I didn't say I don't like EJB. I do, however, agree with the post that claimed that it is often used inappropriately, and for some of the same reasons the poster mentioned. In my big app, the relationship between what's in the database and what the user sees is often very complex. Simplistic models such as those you mention (CRUD/Master-Detail/multi-row updates) just wouldn't work. The model, then, is provided by an API that abstracts the true data model underlying the application. The API is application-independent, so that I can build a Struts app, a WebStart app, an applet, a command line tool - and probably a Velocity app, although I haven't tried that - on top of it, without any cross-dependencies. The list of models you mention is rather telling. They are all based on simple database manipulation. Certainly, this is likely to cover a good many Struts applications, but it's a rather restrictive viewpoint. Many web apps out there require complex database manipulation or do not use relational databases at all. The Struts-aware code in a Struts app should not necessarily be aware that a database is involved in the model at all. By the way, you mention that "If you do use formbean as a model you can unit test it". That may be true, but it's actually a lot easier to write unit (and functional) tests for an API when it doesn't require me to drag in unnecessary packages such as Struts, servlets, etc. Finally, I don't understand "If people use JSTL.... Then use formbeans as model". JSTL is very cool, and I plan on taking full advantage of it in future apps, but I'm certainly not planning on using form beans as my model. Perhaps you're referring to the sql taglib, which I'm not planning on using at all. (If I said I was, Craig would probably shoot me! :) Personally, I find it sad that you're teaching the use of Struts in ways which violate its design principles. Given my own personal experience, I still maintain that, if people are taught well on the value of MVC, and why Struts is the way it is, then they can be productive in developing Struts apps the way they were intended to be built. And they don't have to learn anything about complex design patterns along the way. (By the way, it's my experience that people are much more likely to buy into a particular design when they understand *why* the design is the way it is.) -- Martin Cooper > -----Original Message----- > From: Struts-dev Newsgroup [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 3:25 PM > To: [EMAIL PROTECTED] > Subject: Re: FormBeans ... as an Interface. > > > Subject: Re: FormBeans ... as an Interface. > From: "Vic C." <[EMAIL PROTECTED]> > === > Martin, > thanks for a reply. Let me see if I can be more coherent and then ask > you a question please. > > Context: > Many intelligent people are implying that formbeans should never be a > model/data layer. I agree with that if one does EJB with Struts. > > However, I found that sometimes it is practical that > formbeans should be > a model/data layer, by simply having formbeans delegate to > DAO and not > have actions transfer from BO or DAO. > I myself have had great success on large projects with this > approach. I > teach this approach. And I recommend this approach to my > clients. On a > big project, KISS works magic. I found it to be more MVC. > So... am I wise to disagree with so many intelligent people? > This is why I started a thread. I first did Struts as per docs, the > formbean not the model approach. > I found that formbean as a model make Struts mode levergable and > competitive to alterative designs. My criteria being how can > a developer > be more productive and write more attainable code. > At least I would like people to say that there are several > designs for > formbeans use, with pluses and minuses, and not "formbeans is not a > model". M > > To my clients I recommed that they use formbeans as a model. > > > I think you said that you do not like EJB much; and would > like to know > how you have personally implemented model > (CRUD/Master-Detail/multi-row > updates) at a high level? > > Minor comments: > - > Users follow code samples, good or bad. > - > The main point is that more people do it wrong, not MVC, > perhaps because > they find it hard. Maybe formbean as model makes it easier. > - > If you do use formbean as a model you can unit test it. > - > The EJB connection is... if you do EJB do not use formbeans as model > otherwise... maybe formbeans should be the model. > - > If people use JSTL.... Then use formbeans as model. > - > Cathedral comment was meant to say, hey, if formbeans as model was > better, than lets keep the door open and not dictate not to do this. > - > I meant to say no need for BO or VO if Formbean is the model. > - > Some people make Struts look like a complex PetStore and not as MVC. > KISS should be advocated. > - > I put webPIM using formbean as model on SourceForge, and was > looking for > a realistic example of formbeans not the model. Some of the comments > about you should do Struts this way, as opposed to the way I > did Struts > was. One is a theory, the other actual. > - > I had wonderful experience using Struts with corporate > developers once I > use formbeans as model. > > Vic > > > -- > 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]>
