FubuMVC or MVCVM?

[DaRage]

I have to say I haven't used FubuMVC and only read some tutorials.
What jumped in my face is the use of "View Models".

Now as far as I know and please correct me if I'm wrong, "View Models"
are part of the MVVM pattern and the're supposed to carry the state
and the behavior of the view. While in the MVC pattern the behavior of
the view is carried out by the controller.

So there is some kind of redundancy and inconsistency since if you put
the behavior in the "View Model" then you end up with controllers that
only delegate to the "View Models". And if you put the behavior in the
controller then you end up with the "View Models" only carrying state
and hence they're not "View Models" anymore but DTOs.

If you choose the first option, then controllers become redundant and
you might as well remove them and make the actions directly in the
ViewModels and end up with MVVM web framework because I think that's
what you guys are essentially doing.

[Jeremy D. Miller]

It's a little bit of an overloading in terms.  The ViewModel in most web MVC scenarios is just a dumb bag of data passed into the View for it to render in a single linear path.  You could technically call it a DTO, but it's mostly about the role it plays in the interactions (the model for the view to render).  MVVM (Presentation Model) is a *stateful* UI pattern connoting a long view lifecyle and is much more of a fit for WPF / Silverlight / WinForms.  Some people will put limited logic into the web VM, but MVVM itself doesn't apply very well to the web world.

And no, we are most definitely not building an MVVM framework.

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: DaRage <dur...@gmail.com>
To: FubuMVC Development Group <fubumv...@googlegroups.com>
Sent: Thu, March 18, 2010 8:09:21 AM
Subject: [fubumvc] FubuMVC or MVCVM?

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-devel+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.

[Chad Myers]

In addition to what Jeremy said about View Models, I'd like to talk about the notion of "Controller".

FubuMVC is a "Front Controller" pattern MVC framework. That means what you know of ASP.NET MVC and MonoRail where there is a class called "Controller" is not applicable here.

In the Front Controller pattern, there is one class that is the "controller". The "Controller" is a more virtual concept which encompasses all the responsibilities that are necessary for processing the request and returning a result. These include but are not limited to: Determining which handler should process the route, constructing the handler, executing the handler, binding the input model, validation, processing the meat of the request (i.e. /login should login the user or return an error), determining the output handler (view, json, etc), constructing the output handler, passing the output model to the output handler, executing the output handler, finishing up the response to the request,  and final cleanup.

These are too many responsibilities for one class called "Controller"  so in the Front Controller pattern, these responsibilities are broken up into "Commands". In FubuMVC, we call these "Behaviors."  Front Controller is also about composing the response.  Sometimes the view needs more information than what is relevant to the "meat" of the request (i.e. displaying the login page may involve displaying advertisements or notifications, etc that are not necessarily the responsibility of the Login action).  FubuMVC embraces this idea, too, and allows greater composition of the response by composing various disparate actions together which all contribute to the overall response while still adhering to the Single Responsibility Principle.

I disagree that we should put the action in the ViewModel, but I do agree that all the little actions that combine to formulate the response should be in separate classes with clear and single responsibilities and FubuMVC should help to facilitate the coordination of all these small actions and bring them all together into the final response.

-Chad

To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.

[Duraid]

I think is overloading of terms is confusing especially when it is borrowed from another pattern that has the same purpose. it's better to call a spade a spade. 

Also, and I'm not too sure about that, but I don't think MVC and MVVM are related to whether they're stateful or not. I know that MVC was invented and used in stateful context, and maybe (again not sure) MVVM can be used in a stateless context. 

To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.

[Duraid]

Thanks Chad. I'm not sure I understand fully but I wanted to say that MVVM comes in 2 flavors View first and View Model first. Maybe the latter is related to what you talked about "Front Controller".  

[m4bwav]

In case your curious here's a link to Martin Fowler's explanation of
the 'Front Controller', http://martinfowler.com/eaaCatalog/frontController.html.

Mark

On Mar 18, 2:09 pm, Duraid <dur...@gmail.com> wrote:
> Thanks Chad. I'm not sure I understand fully but I wanted to say that MVVM
> comes in 2 flavors View first and View Model first. Maybe the latter is
> related to what you talked about "Front Controller".
>

> > On Thu, Mar 18, 2010 at 8:56 AM, Jeremy D. Miller <jeremydmil...@yahoo.com

> > > wrote:
>
> >> It's a little bit of an overloading in terms.  The ViewModel in most web
> >> MVC scenarios is just a dumb bag of data passed into the View for it to
> >> render in a single linear path.  You could technically call it a DTO, but
> >> it's mostly about the role it plays in the interactions (the model for the
> >> view to render).  MVVM (Presentation Model) is a *stateful* UI pattern
> >> connoting a long view lifecyle and is much more of a fit for WPF /
> >> Silverlight / WinForms.  Some people will put limited logic into the web VM,
> >> but MVVM itself doesn't apply very well to the web world.
>
> >> And no, we are most definitely not building an MVVM framework.
>
> >> Jeremy D. Miller

> >> The Shade Tree Developer <http://codebetter.com/blogs/jeremy.miller>
> >> jeremydmil...@yahoo.com
>
> >> ------------------------------
> >> *From:* DaRage <dur...@gmail.com>
> >> *To:* FubuMVC Development Group <fubumv...@googlegroups.com>
> >> *Sent:* Thu, March 18, 2010 8:09:21 AM
> >> *Subject:* [fubumvc] FubuMVC or MVCVM?

> >> fubumvc-deve...@googlegroups.com<fubumvc-devel%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/fubumvc-devel?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "FubuMVC Development Group" group.
> > To post to this group, send email to fubumv...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > fubumvc-deve...@googlegroups.com<fubumvc-devel%2Bunsu...@googlegroups.com>

[Jeremy D. Miller]

I think you're alluding to "View First" or "Presenter / ViewModel First" navigation (does the presenter tell the view to go, or does the view get placed then tell the presenter to start).  That's an orthogonal topic that doesn't have any relevance to a web app.

 

Jeremy D. Miller
The Shade Tree Developer

jeremy...@yahoo.com

---

From: m4bwav <m4b...@gmail.com>

To: FubuMVC Development Group <fubumv...@googlegroups.com>

Sent: Thu, March 18, 2010 2:36:03 PM
Subject: [fubumvc] Re: FubuMVC or MVCVM?

> >> fubumvc-devel+unsub...@googlegroups.com<fubumvc-devel%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/fubumvc-devel?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "FubuMVC Development Group" group.
> > To post to this group, send email to fubumv...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > fubumvc-devel+unsub...@googlegroups.com<fubumvc-devel%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/fubumvc-devel?hl=en.

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To post to this group, send email to fubumv...@googlegroups.com.

To unsubscribe from this group, send email to fubumvc-devel+unsub...@googlegroups.com.

[Chad Myers]

Well, we were using Presentation Models and View Models before MS folks coined MVVM. So I can see how it can be confusing if you're coming from a MVVM background.  But View Model is not owned by the MVVM pattern (which is really a co-opting of other patterns) and the pattern name (View Model) is still meaningful.

Viewmodels in FubuMVC *can* have behavior, but don't have to.  Since web frameworks are not stateful, it doesn't make as much sense to have behavior in the model as it does in Presentation Model (or what they call MVVM).

The pattern is useful for having the action produce data to which the view can bind. This data can be entities directly, or DTOs, or a fatter object that has flattened data plus a little behavior.  The idea is to not stuff a bunch of junk into a dictionary bag and have to fish it out later (a la ViewData[]).

-Chad

[Chad Myers]

FubuMVC has nothing to do with MVVM. As Mark (m4bwav) pointed out, Front Controller is a variation or style of MVC.   Front Controller doesn't deal with models and how they are passed to and bound in views, however. 

-Chad