I think this is what we get using GWT:
|------------- Client ----------| |--------------- Server ----------------| Views and Controllers Controllers for domain logic |-------------------------------- Model -----------------------------------| On the client side we've classes responsible for handling the user interaction, nothing beyond this. On the server side we've the system's logic, all the calculations, validations, and all other requirement are made here. And the model is shared between them. We still have the separation of concerns but with a smarter view (the client side) than the old full refresh. Regards, --- Felipe Marin Cypriano Vitória - ES http://www.linkedin.com/in/felipecypriano On Wed, Feb 25, 2009 at 12:22 PM, gregor <[email protected]>wrote: > > Hi Reza, > > I think I made an unfortunate choice of words with "dogma". I do not > mean to diss MVC, what I really meant to convey was that there is an > awfull lot more documentation around about MVC than there is about > Model Delegate and the the use of the Observer and Mediator patterns > in this context. You are quite right IMO that newbies should learn and > apply well established patterns, but my point is that the MVC pattern > has so much exposure that it is possibly unbalanced. > > I think part of the reason relates to your comment: > > "And finally, I don't have anything against ModelDelegate, but I think > you wouldn't use it in a jsp web site by putting all controllers code > inside jsp. (which is possible and most newbies start coding this way) > You definitely use a well established MVC framework." > > You are undeniably right about this: you should definitely use a MVC > framework like struts for a JSP based application. The thing is, > though, that JSP based applications are a perfect fit for the MVC > pattern since each request from a view needs to be processed and > redirected to the next view. A struts Action class, i.e. a controller, > is perfect for this. MVC got a huge boost to its profile through > struts and JSP Model 2. > > But a GWT AJAX application is a different animal. It is technically a > "thin client" since it runs in a browser with no native executables or > libraries required, but functionally it has a lot more in common with > a traditional "thick client" - complex UI, no paging, asynchronous > server calls, session state shifted from server to client etc. In a > Java thick client, say Swing, you typically set a model graph directly > on a widget, and the widget binds itself to it and controls user > events and how they affect the model. > > In GWT it is similar to this, because events are propagated from the > browser via the widgets themselves, so if you have separate > controllers that need to know about events (which they do) it can > become complicated and messy. This is exacerbated by the asynchronous > RPC mechanism as Charles pointed out in the OP. If a widget itself is > not coordinating the asynch call, but calls a method on a separate > controller, you need another callback mechanism to relay the results > back to the widget. > > There are situations where doing this is necessary. My favourite > example is a work flow application where a work flow process may have > many different views all of which are based on the same model graph > for the process. In this case a MVC decomposition some thing like this > makes sense: > > view > / \ > controller \ > / \ \ > / \ \ > RPC \ \ > \ --- model > > IMO in many, if not most, situations that is over-engineering. > > However none of this answers the OP question really, nor does it > answer your point that newbies should follow good practice based on > known sound patterns. If not MVC then what exactly? To be sure the > answer is not that well documented. The current GWT event system which > is based pretty much on the Observer pattern. it works well in the > simple case but has shortcomings when you scale in terms of > complexity. It can get messy with dozens of different listener > interfaces etc. I think the new event system coming in with 1.6 will > make a big difference to this. > > My own response has been to experiment with the Mediator pattern as > defined in the GoF book. I am pleased with the results so far. The GoF > book actually uses a set of collaborating widgets as the example for > Mediator. I use a mediator to coordinate events between colleague > widgets (usually Composites) around a specific functional area. The > Mediator only handles event subscription, publishing and routing. The > Composites themselves are responsible for deciding what to do in > response to a particular event. The main shortcoming of this approach > I have found so far is if an event requires several Composites to > refresh their data at once since this implies multiple concurrent RPC > calls when one would be better. I'm still thinking about how to best > deal with that in general terms. > > Anyway, I have nothing against MVC, only that it is not IMO an > automatic or universal best choice for a GWT client. Only sometimes. > > regards > gregor > > > > > > > On Feb 25, 1:35 pm, Adligo <[email protected]> wrote: > > Hi charles, > > > > I have also written and open sourced a mvc architecture (gwt_util > > and gwt_util_demo) projects at;http://www.adligo.com > > It is designed specifically to be used with storage (databases, ldap > > servers, files exc). It also has a logging framework, so you can > > figure out whats going on in my gwt mvc classes. > > Give the large number of gwt mvc architectures out there I would > > have to say it is a good idea. On thing it took me years to realize > > (due to falling asleep in computer science 1?) is that mostly when you > > hear the words re-use they pertain to re using a design (like mvc, > > observers, command patters, exc) and not actual code (although that is > > quite useful too). > > > > Cheers, > > Scott > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
