I'm trying to educate myself and learn up on MVVM. At the moment, I'm just trying to get my arms around Rocky's ultra light-weight bfx framework used in the CSLA demos. I get most of what's in the
http://www.lhotka.net/Article.aspx?id=389bb59d-2760-4309-aee2-f55a976ef100
Will I need to create a ViewModel class that is utilized by a presenter class for EVERY csla object? Further, will I have a presenter for every ViewModel? In the bfx example there's a hard coded "start" int and the presenter is shared amongst multiple ViewModels based on the hard coded value - it isn't clear to me if that was just done to save time or if there's something I'm missing here.
If there's a viewmodel and presenter for each "model" being a csla object, that seems somewhat excessive to me for items like readonlylists that populate things like drop downs with one way bindings. Am I missing something here? is there a value add that I don't get?
Rocky has a video series on the subject that you can buy for a nominal price. It goes through the basics and gets you a good start.
I've used bfx to learn MVVM and I'm glad to have had it as a resource. We should remember that the B stands for Basic, and it probably isn't the best viable option for writing larger applications as it has some difficiencies that require a lot of coding to implement. I'm not trying to knock bfx, just understand what it is and you'll be fine.
Thanks, yea, that's why I chose it as a starting point.
Oh yeah, how about a link?
And does anyone know what the deal with this hard coded "start" variable I mentioned is?
Okay, so while I do plan to get the MVVM video at a later date, I've went ahead and moved toward the MVVM light framework.
I've listened to Rocky's introductory video and it all makes a lot of since as I am starting to get the goals behind the pattern and why they're there. I still don't see a clear solution on how to incorporate CSLA into the picture in some places. For example, some UI specific things business logic (like wizards for example) do not make much since to make into a csla model (though I COULD see advantages if you wanted to utilize it for validation purposes). Anyway, I end up with models that aren't csla models (mixing rich and non-rich models into one app). Is it bad practice to include some of these concepts directly into the CSLA viewmodel and not create models for the smaller pieces? (i.e. you have a ShoppingCart CSLA object and a ShoppingCartVm view model that also encapsulates the wizard concepts instead of creating a Wizard model object and a WizardVm).
With bfx, I see an immediate need to create a view model for every csla object, since the ViewModelBase class utilizes a "Model" property by design. I like the simplicity of this, but MVVM light however provides you the ability to implement your own properties in ViewModelBase giving the developer the capability to "alter/reorg" the interface to the view model compared to the interface of the model itself. Now, I'm trying to understand, is this a good thing to do or bad?
And with MVVM light, I could see it possible to create just one viewmodelbase that's used for EVERYTHING. That doesn't seem to be best practice, but why not?
Consistency between layers makes things easy to interpret, but implementing a view model for EVERY read only list seems excessive in some cases. Applications that utilize lots of drop downs == lots of view models whose only purpose is to provide a data connectivity test.
In MVVM light, it seems that you could, say create a single view model for such items called something like "DropDownsVm" or something, and then create a property that serves up your csla model ReadOnlyList object.
I was just curious what other people out there are doing, keep the layers consistent, or simplify it a bit for things like this? Thoughts?
I also ran into this situation and I'm unsure if I'm on the right track:
class A is a BusinessBase. Class B is a ReadOnlyList. Class A has property Foo. On the UI, when A.Foo changes, B fetches new values based on A.Foo.
The ViewModel layer consists of ClassAViewModel, which exposes these properties:
Model (an instance of class A, the BusinessBase)
ListB (an instance of class B, the ReadOnlyList)
Instantiating this viewmodel adds a property changed eventhandler on Model.Foo to refresh ListB with the appropriate contents.
How would this be done if you had one View Model for every CSLA object? I obviously just don't get something, because based on the way I'm doing things this wouldn't be possible in BFX due to the single Model property.
I know I'm at least in the right direction, because I've eliminated codebehind entirely, but I'm not sure if I've got the whole pattern down right based on the above. I wire up the View to the ViewModel fine, but I don't know if my ViewModel layer is "standard". am I on the right track?
I think Rocky's video series will help with these questions, but ultimately it looks to me like you're trying too hard. 
Because of the nature of CSLA BO's, ViewModels in that space don't function quite like other places. CSLA objects already have what they need to essentially function as a viewmodel - they support binding, have the business rules (and associated UI interaction capabilities), etc. And when you throw in the concept that CSLA BO's should be built around necessary behaviors instead of data, they end up looking an awful lot like ViewModels in other MVVM scenarios.
As such, Rocky's recommendations have been that VM's you create in CSLA are there for you to create methods/properties that support the UI functionality. The "Model" property contains your CSLA BO (or your CSLA BO list), which you directly bind to in your UI for everything else. As such, you don't have to create a VM for every single CSLA BO you have. Again, the videos go over this in greater detail, but in your list situation, I only see a need for one VM that wraps Class A. You don't need a VM for your list, since that's there presumably to support data within Class A.
There also isn't necessarily a restriction to one "Model" property. AFAIK, you can have as many "Model" properties as you want - they're just different paths in your XAML databinding. There's certainly nothing stopping you from creating multiple (possibly nested) ViewModels, much like you'd construct your CSLA BO graph. But there isn't a "one model object per VM" restriction that I know of.
HTH
- Scott
Unless the list is a child of A, how would you bind it to the view without a view model? Do you typically structure your lists as child objects if they are to be used by A? I suppose the traditionalist "use-case" philosophy recommends that, though I don't always go that route.
Yes, clearly I haven't reviewed bfx in great detail, but in MVVM light you just add your properties to an extended ViewModelBase class. I guess what I'm referring to is what I've seen so far in the examples and the class design I've seen thus far - A generic parameter defines the type for the "Model" property which is then binded to the views xaml. So I guess you're suggesting (if you want to have multiple objects to one view model) just extend extend extend, which I suppose could be possible but kinda clustered!
Quite possible :) I do that. Though I've just been confused with bfx is all. MVVM I picked up very quick and was immediately hooking up relaycommands to my CSLA etc. But if I apply the same approach in bfx the train stops hehe. I'll just have to wait and check out the videos when I have time. Thanks for the help so far.
In the mean time, I've atleast solved the problems that MVVM sets out to solve with MVVM Light... I now have a completely bind driven separation to test with.
Unless the list is a child of A, how would you bind it to the view without a view model? Do you typically structure your lists as child objects if they are to be used by A? I suppose the traditionalist "use-case" philosophy recommends that, though I don't always go that route.
Just like you did in pre-XAML UI's. CSLA objects are bindable in and of themselves, so there's nothing stopping you from binding your XAML forms directly to your CSLA BO's. In fact, that's what Rocky encourages. The path capabilities of XAML-based binding make this rather simple.
In terms of your specific scenario: no, I would not make your list a child of A. I'd use a Unit Of Work object. Then your Class A and your List B would be "children" of the UOW. You still don't have to create a VM for your child list, nor do you really have to create one for your UOW object. Remember - in the CSLA world, VM's are there to support UI-specific methods/properties, not to wrap your CSLA object. Ultimately, when you're binding your XAML UI, most of it is going to bind directly to your CSLA BO properties/methods. It takes a small amount of gymnastics, but in the end the UOW is your main DataContext, and your child VM pulls from that (and becomes the DataContext for your Class A "region"), while your read-only list is directly bound to whatever list control you have that it's supposed to populate. Again, the path capabilities of XAML binding make this relatively easy.
Yes, clearly I haven't reviewed bfx in great detail, but in MVVM light you just add your properties to an extended ViewModelBase class. I guess what I'm referring to is what I've seen so far in the examples and the class design I've seen thus far - A generic parameter defines the type for the "Model" property which is then binded to the views xaml. So I guess you're suggesting (if you want to have multiple objects to one view model) just extend extend extend, which I suppose could be possible but kinda clustered!
Again, you may want to look at UOW objects. And I think the first video in the series (which at least at one point was free) touches on how Rocky sees building VM's using CSLA objects. BXF is designed to support that type of VM construction, as are the base VM classes he created.
Though I've just been confused with bfx is all. MVVM I picked up very quick and was immediately hooking up relaycommands to my CSLA etc. But if I apply the same approach in bfx the train stops hehe. I'll just have to wait and check out the videos when I have time. Thanks for the help so far.
In the mean time, I've atleast solved the problems that MVVM sets out to solve with MVVM Light... I now have a completely bind driven separation to test with.
There's nothing wrong with using MVVM Light over BXF - in the end, it's whatever you can grok and get working. MVVM Light is a great product, and if you can get it work, then by all means use it! MVVM Light is built on a "one model, one VM" concept, because it's mainly there to assist in the "dumb model" concept (of which CSLA is not).
The last thing to consider is that BXF is, primarily, a teaching tool - it's certainly useful in some scenarios, but Rocky wasn't intending to create a full-fledged "production ready" MVVM framework. BXF is basically showing you the minimum level of coding necessary to support the MVVM style of development.
HTH
- Scott
The last thing to consider is that BXF is, primarily, a teaching tool - it's certainly useful in some scenarios, but Rocky wasn't intending to create a full-fledged "production ready" MVVM framework. BXF is basically showing you the minimum level of coding necessary to support the MVVM style of development.
Absolutely! Bxf doesn't really compare with full featured UI frameworks, and isn't intended to do so. It is intended to show the minimum necessary plumbing to support the MVVM design pattern.
Also, to reinforce what Scott has said, I am a firm believer that there are two types of 'model': anemic and rich.
Most MVVM (and MVC/MVP) examples assume an anemic model, where the model is composed of objects that just contain data. Not smart, not bindable - dumb-ass objects that just contain data. Like you get from the EF designer, or adding a service reference.
And that's fine if that's all you have.
But if you are using CSLA, then you have a rich model. Moreover, your model should have been designed following your user scenarios (user stories, use cases, etc), and therefore should directly reflect the needs of the particular scenario where the objects will be used. Just like the UI (views).
The result is that the objects already have the right shape for the view. So you don't need a heavy-weight viewmodel to reshape the model, or to add data binding, or to invoke business rules - because the model already does all that.
Therefore, the viewmodel becomes simple. Its primary job is to add UI-specific verbs (methods) that wouldn't naturally be part of the model. And sometimes (often?) also add UI-specific derived properties (like a FullName property, or an Age property - all calculated off the underlying model properties).
The ViewModelBase/ViewModel classes in Csla.Xaml help you do this.
Bxf is a completely separate thing. Totally separate. It has nothing to do with CSLA at all. The only connection is that I created Bxf so I had a super-simple UI framework for building CSLA samples. But Bxf works without CSLA, and CSLA works without Bxf.
The really, really, really important thing to understand is that properly designed CSLA business object models are a 'rich model' for MVVM, so your viewmodel types can be simple. If your viewmodel is complex (and you have a CSLA model), you are doing something wrong.
All: thanks for the help. Rocky, thanks, your first video illustrates all these points quite well. What I'm missing though, is while I understand csla is a rich model, the UI specific stuff (like if the user changes a property on one object and you need to go fetch a new RO list) Should I be making a ViewModel for both objects? Or may I just create one view model that exposes both objects? I've been doing #2 and am afraid that's bad practice.
Yes, I understand binding - but how would you do it WITHOUT a view model and still be MVVM? tmg4340 said "You don't need a VM for your list, since that's there presumably to support data within Class A." I must be missing something here...
I always have at least one viewmodel per view. The view binds to the viewmodel, and often binds to the model via the Model property of the viewmodel.
Sometimes my viewmodel will have several "Model" properties if the view requires access to several objects. This is pretty common if you are using a UOW model object to retrieve several other objects.
I do not always have a viewmodel for every child object or child control in the view. A viewmodel is typically only necessary when you need to add verbs or calculated properties to the model.
So you always need at least one viewmodel, because that's what the view binds to - and that top-level viewmodel always manages retrieval of the object(s), and often provides Save/Cancel verbs.
But you may or may not need a viewmodel to add verbs to child objects as they are bound to child controls in the view.
Copyright (c) Marimer LLC