Speaking philosophically, I don't think that MVC is an end in itself; the reason this pattern has value is because it makes code easier to understand, maintain, and extend. Considering that any application of MVC to a HTTP environment is necessarily going to be a bastardization of the canonical Smalltalk pattern (you cannot implement Observable), it seems silly to be religious about it. Sometimes it makes a lot of sense to use the Controller object itself as the model, especially for simple form processing.
For some discussion of exposing entity beans to the presentation layer, I suggest haunting some of the forums on theserverside.com. I would concur with the wisdom of hiding all entity beans from the presentation layer, and the PIG sample application provides several examples of why. Entity beans have a long way to go before they can wholly replace direct database access; since EJB QL offers no aggregation functions, there are quite a few queries that are either impossible or prohibitively slow without hand-coded SQL. If your data model is directly exposed to clients, your ability to perform special processing to arrive at the data is quite limited. Actually, I'm starting to form the opinion that entity beans are a rather ill-conceived part of the EJB specification, and it wouldn't surprise me if they fall out of popularity when JDO matures. Dunno. I use them, but I find myself working around them often enough to keep looking for something a lot better. I'm glad your system is working now, though. Ultimately, the best code is the code that is already written and works properly :-) Good luck! Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: Gerald de Jong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 12:40 AM > To: [EMAIL PROTECTED] > Subject: RE: [Mav-user] EJB/Maverick > > interesting that this would be conventional wisdom. the pure MVC > structure > of Maverick/XSL would seem to make a case for reviewing this wisdom. the > bean is a convenient thing to pass into the pipeline. > > (actually, i can no longer figure out what the problem was because it > seems > to work now. i'm giving EJBs directly to the domifier.) > > it surprises me to see that you're happy to muddle MVC by making your C > also > the M, merely for "convenience"! i would suggest that the most convenient > approach would be to create a public inner class as model, because this > doesn't take the umph out of MVC. > > On Thursday 17 January 2002 04:45, Jeff Schnitzer wrote: > > I've never tried using an EJB directly as a model; it doesn't seem like > > a very good pattern. Conventional wisdom in EJB programming seems to be > > to hide entity beans behind a session bean fa�ade, returning value > > objects. If all you have to worry about is a single bean, I find it > > convenient to use the Controller object itself as the model. > > > > Still, I'm surprised that it didn't work. Domify should be able to wrap > > anything. What was the error? > > > > Jeff > > > > > -----Original Message----- > > > From: Gerald de Jong [mailto:[EMAIL PROTECTED]] > > > Sent: Saturday, January 12, 2002 1:11 AM > > > To: [EMAIL PROTECTED] > > > Subject: [Mav-user] EJB/Maverick > > > > > > i'm having some big fun working with Maverick and JBoss to create a > > web- > > > app. > > > > > > but it made me wonder: when the controller deals with EJBs it will > > have > > > to > > > work with their remote interfaces. i was not successful when i tried > > to > > > incorporate the EJB interface itself in a Maverick model, i think due > > to > > > the > > > remote exception that can be thrown. i had to create a special model > > bean > > > for the domifier. > > > > > > am i missing something? > > > > > > -- > > > Beautiful Code BV > > > Rotterdam, The Netherlands > > > http://www.beautifulcode.nl > > > > > > _______________________________________________ > > > Mav-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/mav-user > > > > _______________________________________________ > > Mav-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/mav-user > > > > > -- > Beautiful Code BV > Rotterdam, The Netherlands > http://www.beautifulcode.nl > > _______________________________________________ > Mav-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mav-user _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
