MVC + RPC architecture

[charles]

Hi,

I am a newbie to GWT and I am trying to develop a web application
using a library (my client API to my server). I have read 2 books
before starting: GWT In Action and GWT In Practice from mannng.
My datas are stored in DB on the server side, that' why I am using
RPC. In addition, I have read that it is better to use MVC concept to
separate datas from view using a conroller. So I am trying to use both
RPC and MVC. I have seen a lot of examples of each one separately but
never together... I have problems to elaborate my architecture with
these two...

My questions are:
- is it a good way to mix these two concepts ?

If yes,
- do I have to duplicate datas in my Model (MVC) ?
- what about asyncCallback when calling a service: whe doing that part
in a widget (view side), I was able to display a window (Window.alert)
when the RPC failed. Now, this code is done in the Model (MVC) so it
doesn't make sense to add this kind of code there...
- how can I handle exceptions? For example, as I can't display a
window in the Model part, I would like throw an exception which will
be thrown from the Model to the View through the controller.. How can
I do that? I can see that onFailure method from AsyncCallback doesn't
throw any controlled exception. In addition, it is an asynchronous
call...

Thank you very much help.

Regards
Charles

[Reza Alavi]

Hi,

You can use GWTruts, it is an open source MVC controller (I am its
developer and I actually implemented it because I needed something
similar to spring MVC).
It provides two types of controllers a standard controller interface
which is a synchronize controller and an AsyncController interface
that you could use if you want to make async RPC calls.

I am going to release something in the next 3 weeks that makes it
possible to use ordinary Spring MVC controllers as GWTruts
controllers. That way you now longer need to worry about aync calls
and async call backs.

I am using GWTruts on a commercial project based on Appfuse (Spring MVC
+ Hibernate+ Maven). It works really good, so if you are familiar with
Spring MVC I suggest you check it at (http://apps.sourceforge.net/trac/
gwtruts/)

As I said I am its developer so I am biased toward it but the main
reason that I developed this code was that I didn't find a pour MVC
implementation for GWT.
All suggestions that I found were about some modified MVC patterns.

In GWTruts you return the name of the next view as the return value of
your controller and you define all the controllers (name->class) and
views (name->class) through XML config files.

Cheers,

[Reza Alavi]

The web address is
http://apps.sourceforge.net/trac/gwtruts/

[federico]

I use PureMvc porting for gwt
http://puremvc.org/
and i like it!

On 24 Feb, 09:18, Reza Alavi <rezaal...@gmail.com> wrote:
> The web address ishttp://apps.sourceforge.net/trac/gwtruts/

[charles]

Thanks for these 2 replies. But if possible I would prefer to use GWT
only. I think there is a way to do that no?
GWT has a RPC feature and is encouraging MVC... I hope they have
thought about mixing them no?

Charles

On 24 fév, 11:07, federico <federico.mona...@gmail.com> wrote:
> I use PureMvc porting for gwthttp://puremvc.org/

[gregor]

Hi Charles,

> - do I have to duplicate datas in my Model (MVC) ?
> - what about asyncCallback when calling a service: whe doing that part
> in a widget (view side), I was able to display a window (Window.alert)
> when the RPC failed. Now, this code is done in the Model (MVC) so it
> doesn't make sense to add this kind of code there...
> - how can I handle exceptions? For example, as I can't display a
> window in the Model part, I would like throw an exception which will
> be thrown from the Model to the View through the controller.. How can
> I do that? I can see that onFailure method from AsyncCallback doesn't
> throw any controlled exception. In addition, it is an asynchronous
> call...
>

You observations illustrate some reasons why when Swing and SWT where
designed they did not follow classic MVC, but implemented a variant of
it sometimes called Model Delegate. It's more convenient and concise.
There are no downsides because there is nothing to stop you
implementing full blown MVC (by which I mean rigorous separation of
view and controller in the UI) if you need to. See:

http://c2.com/cgi/wiki?ModelDelegate

GWT is loosely based on Swing/SWT programming model (as far as it can
given it runs as javascript). It makes sense to follow the programming
model of your tool kit, or at least to investigate why it follows the
pattern it does, rather than blindly follow traditional MVC dogma.

regards
gregor

[stone]

how do u think about
http://gwt-mvc.googlecode.com/

[Reza Alavi]

Hi Gregor,

I think I need to clarify something.

We didn't follow MVC dogma blindly!
Based on experience on working on large scale projects we know that
there is no other good option available to develop and "maintain"
enterprise level applications.
I know that not following well established patterns might seem easier
at first but in a long run the price that you would pay for the
maintenance gonna be much higher.

Honestly, suggesting MVC patterns is more like sharing experience than
a religious war.

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.

My point is know that we have other lightweight frameworks that claim
they provide full MVC support we should consider them more seriously.

Kind regards,
Reza.

[Adligo]

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

[gregor]

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

[Felipe Cypriano]

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