CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Status and Recommendations on CLSA, MVVM and Universal Apps

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 9 Replies | 3 Followers

    Top 150 Contributor
    64 Posts
    nhwilly posted on Sun, May 11 2014 6:23 PM

    Getting back into it all from some time away and trying to match all the proper bits together to get started.  Universal App templates seem like a good idea and I know CSLA is something I want.  MVVM makes a ton of sense.

    Not really sure if there is a recommended MVVM toolkit or framework, though.  I see lots of activity on MVVM Light.

    I haven't investigated fully, but it seems like there might be some overlapping functionality between CSLA and MVVM Light when it comes to properties and their changed events.

    Primary target is WP8.1 and ASP.NET MVC.

    Any guidance or recommendations?

    Any giant bear traps I have to look out for?

    TIA

    Huh? What? Huh?

    Answered (Verified) Verified Answer

    Top 10 Contributor
    9,475 Posts
    Verified by nhwilly

    There are two primary reasons for creating a viewmodel in the first place:

    1. Reshape the model to match the view because the model wasn't designed for the user scenario
    2. Add verbs (methods) unique to the UI that don't make sense in a business context

    If you are using CSLA correctly, your objects will be designed to match the user scenario, so the first reason for having a viewmodel no longer makes any sense.

    The second reason often makes sense, because it is quite common to handle various UI events, but it wouldn't make sense for those methods to be in the business classes.

    Of course it is an anti-pattern to use a design pattern just for the sake of the pattern - you should always use patterns because they provide value.

    So the question is how (or if) you should use MVVM to get value without incurring extra coding/testing effort.

    Replicating all your model's properties in a viewmodel is totally pointless if the model is already in the right shape, and if the model already supports data binding. As I say, if you are using CSLA correctly then your model will be in the right shape, and will support data binding. As a result your viewmodel shouldn't replicate all the properties - that's just extra cost and code and mess for no value at all.

    However, having a viewmodel for your verbs probably still makes sense. So then the question is how to let the view bind to the business object, and also add verbs to a viewmodel.

    The examples in the 'Using CSLA 4' book show how to do this, as do a number of the samples in the CSLA download. In short, your viewmodel has a Model property that exposes the business object for binding to the view, and the viewmodel also implements any verbs necessary to work with the UI.

    Easy, effective, and this approach doesn't increase the cost/coding/testing/maintenance burden by making you write a bunch of useless code just for the sake of blindly following a pattern.

    Rocky

    All Replies

    Top 25 Contributor
    498 Posts

    Hi,

     

    Have a look at CSLA .NET Contrib. It includes a library to use Caliburn.Micro with CSLA .NET

    Tiago Freitas Leal, CslaGenFork (Open Source CSLA code generator)

    Top 150 Contributor
    64 Posts

    Tiago,

    I think MVVM Light gets more press, but I'm not sure which is the better framework. 

    Checking out CM now.

    Thanks. 

     

    Huh? What? Huh?

    Top 10 Contributor
    4,106 Posts
    Andy replied on Mon, May 12 2014 6:18 PM

    Regarding Csla and property changed events, you'll likely bind your view directly to the Csla model, or the Csla model will be a property of your view model and so the property changes would be needed only from the new properties of the view model.

    Top 150 Contributor
    64 Posts
    nhwilly replied on Tue, May 13 2014 11:54 AM

    Thanks for the reply.

    OK, but doesn't that mean my View and my Model are more coupled than I want them to be?  I mean, if I followed MVVM to the letter, wouldn't my View Model subscribe to my model notifications and my View subscribe to my View Model notifications?

    Huh? What? Huh?

    Top 10 Contributor
    4,106 Posts
    Andy replied on Tue, May 13 2014 12:28 PM

    nhwilly:

    Thanks for the reply.

    OK, but doesn't that mean my View and my Model are more coupled than I want them to be?  I mean, if I followed MVVM to the letter, wouldn't my View Model subscribe to my model notifications and my View subscribe to my View Model notifications?

    Yes, but I'd have to ask why you'd want to write all that code that listens for events from your model just so your VM can re-raise them?  The VM is meant to supplement what your model can do, not replace it. 

    Top 150 Contributor
    64 Posts

    I can see that would technically work, but doesn't that link the View a little too closely with the Model?

    Wouldn't properties that changed in the model bubble up through the view model and on to the view?

    Huh? What? Huh?

    Top 10 Contributor
    4,106 Posts
    Andy replied on Wed, May 14 2014 11:02 AM

    Have you checked the Mvvm sample that comes with Csla?  I think that will answer a lot of your questions.  Your view and model are tied pretty closely anyway though; the view is how the user interacts with your application to execute the use case, and your model's job is to implement the behaviors for that use case.  A VM can supplement by taking care of things that really are UI concerns, but most of the behavior you want is already in your model.

    Top 10 Contributor
    9,475 Posts
    Verified by nhwilly

    There are two primary reasons for creating a viewmodel in the first place:

    1. Reshape the model to match the view because the model wasn't designed for the user scenario
    2. Add verbs (methods) unique to the UI that don't make sense in a business context

    If you are using CSLA correctly, your objects will be designed to match the user scenario, so the first reason for having a viewmodel no longer makes any sense.

    The second reason often makes sense, because it is quite common to handle various UI events, but it wouldn't make sense for those methods to be in the business classes.

    Of course it is an anti-pattern to use a design pattern just for the sake of the pattern - you should always use patterns because they provide value.

    So the question is how (or if) you should use MVVM to get value without incurring extra coding/testing effort.

    Replicating all your model's properties in a viewmodel is totally pointless if the model is already in the right shape, and if the model already supports data binding. As I say, if you are using CSLA correctly then your model will be in the right shape, and will support data binding. As a result your viewmodel shouldn't replicate all the properties - that's just extra cost and code and mess for no value at all.

    However, having a viewmodel for your verbs probably still makes sense. So then the question is how to let the view bind to the business object, and also add verbs to a viewmodel.

    The examples in the 'Using CSLA 4' book show how to do this, as do a number of the samples in the CSLA download. In short, your viewmodel has a Model property that exposes the business object for binding to the view, and the viewmodel also implements any verbs necessary to work with the UI.

    Easy, effective, and this approach doesn't increase the cost/coding/testing/maintenance burden by making you write a bunch of useless code just for the sake of blindly following a pattern.

    Rocky

    Top 150 Contributor
    64 Posts

    It's been a while since I've been in it and I've already read the books twice.  Doesn't do me much good unless I apply it all right away.  Senior moments.

    Thanks for the review.  Didn't mean to make you go through that.

    Huh? What? Huh?

    Page 1 of 1 (10 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems