MVVM Framework?

MVVM Framework?

Old forum URL: forums.lhotka.net/forums/t/8075.aspx


dlambert posted on Wednesday, December 02, 2009

I've seen some MVVM articles that list some of the available frameworks - ex:

http://www.japf.fr/2009/10/a-quick-tour-of-existing-mvvm-frameworks/

I know that CSLA's got a bunch of support for MVVM now, but in terms of positioning CSLA, would it be more accurate to say that CSLA *is* an MVVM framework, or that it *supports* any of these other MVVM frameworks?

The problem I've got with the latter statement is that I think CSLA overlaps the functionality of a lot of these frameworks, many of which seem to encourage the use of "weak" viewmodels (which I think we'd all agree is not what we'd prefer to see).

Maybe this is a case that clarifies the "splitting assemblies" debate -- if "CSLA-MVVM" (or CSLA-XAML) were visible as a separate development entity, I think it would make sense to promote CSLA-MVVM as a great MVVM framework that just happens to require (or encourage) the use of CSLA-Core to build its models. CSLA-Core, on the other hand, is how you build great models, no matter what UI you want to slap on top of them.

I know this is sort of a squishy topic, but I'd like to see CSLA get more attention / kudos, and I'd love to have a clean message to inject CSLA into discussions like the one above.

RockfordLhotka replied on Wednesday, December 02, 2009

CSLA .NET includes enough functionality that you can consider it to be a basic MVVM framework, yes.

MVVM is a design pattern, not a technology. It merely specifies that you have a view, a viewmodel (1 or more) and a model. To make this work, the only thing that's really missing in XAML is a general way to invoke methods on the viewmodel in response to arbitrary UI events, and CSLA does this through InvokeMethod and Execute (depending on whether you want to use Interactivity or not).

Technically nothing else is required to be an "MVVM framework".

This is not to say that CSLA is a UI framework. That is a whole other thing, and requires MVC/MVP or other UI patterns and runtime elements. I don't plan to go there :)

I've posted and blogged a few times about the two general types of viewmodel - the lots-of-work type where the VM replicates much/all of the Model. That's good (required) for an anemic Model, but is really pretty silly if you have a rich model. Then there's the type of VM that exposes and extends the Model, often requiring very work to create the viewmodel. This works great for a rich Model (like CSLA objects), but is pretty useless with an anemic model.

You can't arbitrarily say one or the other is "right", because it depends entirely on whether you have an anemic or rich model.

Copyright (c) Marimer LLC