Coffeehouse Thread

28 posts

MVVM

Back to Forum: Coffeehouse
  • User profile image
    wesaday

    spivonious said:

    I found this blog post which builds a very basic MVVM app around a DataSet. It still seems like an unnecessary separation to me, but it does make the code more structured.

    http://wesaday.wordpress.com/2009/02/13/mvvm-in-wpf-part-ii/

    John - the DataSet designer isn't part of the applications View...I'm confused as to why yout think I'd need to create everything in code.

    To be fair the example was not buillt around a dataset. A dataset was used because that bit of code was being used and reused around the other code examples.

  • User profile image
    aL_

    i used to consider mvvm overkill but then i found out that it can be used for design time data when i make the actual ui.. design time is huuuuugely helpful esp, if you're doing any kind of templating Smiley

    also regarding the repository pattern, sure its not often that one rips out the entire database, but as soon as you want to mock your DAL, you'll be glad you used the repositry pattern Smiley i also find it rather nice to have all the database code in one place, and thats the whole idea with repositories Smiley  

  • User profile image
    vesuvius

    aL_ said:

    i used to consider mvvm overkill but then i found out that it can be used for design time data when i make the actual ui.. design time is huuuuugely helpful esp, if you're doing any kind of templating Smiley

    also regarding the repository pattern, sure its not often that one rips out the entire database, but as soon as you want to mock your DAL, you'll be glad you used the repositry pattern Smiley i also find it rather nice to have all the database code in one place, and thats the whole idea with repositories Smiley  

    i.e. use stored procedures, something not necessarily promoted by MVVM:P .

    I thought the shift to MV-VM [in this specific scenario only] a case of a "square peg in a round hole". You don't get a takeaway only to get home, and cook it again, much like ignoring the datasets change-tracking, just so you can inflate your object count inheriting ObservableCollection and re-implementing most of the same logic.

    Stellar advice has been provided by Messrs "WPF Disciple" and "Askew", and one could never hope to shine a brighter light on the subject.

     

  • User profile image
    aL_

    vesuvius said:
    aL_ said:
    *snip*

    i.e. use stored procedures, something not necessarily promoted by MVVM:P .

    I thought the shift to MV-VM [in this specific scenario only] a case of a "square peg in a round hole". You don't get a takeaway only to get home, and cook it again, much like ignoring the datasets change-tracking, just so you can inflate your object count inheriting ObservableCollection and re-implementing most of the same logic.

    Stellar advice has been provided by Messrs "WPF Disciple" and "Askew", and one could never hope to shine a brighter light on the subject.

     

    well even if you use stored procedures you still need to call them from somewhere in your code, thats where the repository comes in, so that you can just swap out those calls for mocked versions.. imo mvvm has very little to do with using stored procedures or not, thats part of the model, not the viewmodel..

    who says you have to ignore the dataset change tracking? just stick datasets in your viewmodel and use INotifyPropertyChanged Smiley you dont have to use ObservableCollection at all (although it may be faster to do so) you could even implement your own thin generic wrapper based on INotifyCollectionChanged around datasets and raise the appropriate events as they are raised by the dataset..

    remember, the viewmodel is just the glue that binds the ui to the model implementation, in this case the dataset [or poco or EF or linq2sql or whatever]

  • User profile image
    aL_

    spivonious said:
    wkempf said:
    *snip*

    Okay, that means I understand the pattern then, which is good. It's definitely different using commands instead of events.

    Thanks everyone for your posts. It's good to see things from a different perspective.

     

    Oh, one last question. My commands (currently just a save and a load) are in the ViewModel, as are the functions they call when executed. Since these functions are just simple mappings to functions in the Model, would it be "wrong" to attach the command execute directly to the model?

    @is it wrong to attatch the command directly to the model

    i'd say it might cause you trouble later on Smiley i think mvvm is that the view only knows about its view model and very little, if anything, else.. it might seem silly to have a command in the viewmodel that just forwards the call to the model, but lets say you want to set some status text in the ui or display an error if the save fails, imo that kind of stuff would go in the viewmodel "Save" command.

    there are no strict rules though, you shold really do what "feels" best, patterns are only guidelines after all Smiley

  • User profile image
    footballism

    aL_ said:
    vesuvius said:
    *snip*

    well even if you use stored procedures you still need to call them from somewhere in your code, thats where the repository comes in, so that you can just swap out those calls for mocked versions.. imo mvvm has very little to do with using stored procedures or not, thats part of the model, not the viewmodel..

    who says you have to ignore the dataset change tracking? just stick datasets in your viewmodel and use INotifyPropertyChanged Smiley you dont have to use ObservableCollection at all (although it may be faster to do so) you could even implement your own thin generic wrapper based on INotifyCollectionChanged around datasets and raise the appropriate events as they are raised by the dataset..

    remember, the viewmodel is just the glue that binds the ui to the model implementation, in this case the dataset [or poco or EF or linq2sql or whatever]

    -> who says you have to ignore the dataset change tracking? just stick datasets in your viewmodel and use INotifyPropertyChanged Smiley you dont have to use ObservableCollection at all (although it may be faster to do so) you could even implement your own thin generic wrapper based on INotifyCollectionChanged around datasets and raise the appropriate events as they are raised by the dataset..

    You don't need to do that yourself, you could simply use BindingListCollectionView to wrap the DataView, and expose it as a property on the ViewModel, BindingListCollectionView will help adapting the Windows Forms' IBindingList contract into WPF's INotifyCollectionChanged contract.

    Disclaimer, binding to ADO.NET data is the buggiest piece of feature inside WPF' data binding subsystem, please take my words serious, since I've done a lot of debugging on ADO.NET binding in WPF:)

    Zhou Yong

  • User profile image
    JohnAskew

    footballism said:
    aL_ said:
    *snip*

    -> who says you have to ignore the dataset change tracking? just stick datasets in your viewmodel and use INotifyPropertyChanged Smiley you dont have to use ObservableCollection at all (although it may be faster to do so) you could even implement your own thin generic wrapper based on INotifyCollectionChanged around datasets and raise the appropriate events as they are raised by the dataset..

    You don't need to do that yourself, you could simply use BindingListCollectionView to wrap the DataView, and expose it as a property on the ViewModel, BindingListCollectionView will help adapting the Windows Forms' IBindingList contract into WPF's INotifyCollectionChanged contract.

    Disclaimer, binding to ADO.NET data is the buggiest piece of feature inside WPF' data binding subsystem, please take my words serious, since I've done a lot of debugging on ADO.NET binding in WPF:)

    Zhou Yong

    BindingListCollectionView -- good information to have, thanks Zhou.

    You don't have issues with ADO Entity Framework and WPF data binding, do you?

  • User profile image
    footballism

    JohnAskew said:
    footballism said:
    *snip*

    BindingListCollectionView -- good information to have, thanks Zhou.

    You don't have issues with ADO Entity Framework and WPF data binding, do you?

    ->You don't have issues with ADO Entity Framework and WPF data binding, do you?

    Well, to be honest, I've never used Entity Framework myself, there are just two many new technologies or even old technologies I need to learn about, Entity Framework is not on the top of my to-learn list:)

    But as long as you are working with POCO, and directly obey INotifyCollectionChanged/INotifyPropertyChanged contract instead of going through BindingListCollectionView adaptation layer, you must be fine with, I think the deep issue right here is that IBindingList notification contract is heavily tested against Windows Forms data binding engine I guess, and when WPF team tried to adapt it into WPF world, better things happen:), I've debugged a weird bug deep inside the ADO.NET DataTable code which misses a critical notification chance to notify the WPF UI as clearly illustrated in those MSDN WPF forum threads:

    http://social.microsoft.com/Forums/en-US/wpf/thread/e9ddd299-4182-4760-9ec8-68f49e8a59ba

    I am the guy who called Marco Zhou, I know I got two many names over the web I know it:)

    Zhou Yong

  • User profile image
    spivonious

    Just had another epiphany:

    To really implement MVVM the way Josh Smith did means I have to duplicate my model in the viewmodel and raise propertychanged events everytime something changes. For his example this isn't a big deal, but for the project I'm hoping to use this for, I'll have 30+ objects, some with more than 20 fields.

    I can appreciate the ease of testing since the view really has nothing to test, but if it means I have to write twice as much code, much of which is a simple copy....I fail to see how I gain.

  • User profile image
    JohnAskew

    spivonious said:

    Just had another epiphany:

    To really implement MVVM the way Josh Smith did means I have to duplicate my model in the viewmodel and raise propertychanged events everytime something changes. For his example this isn't a big deal, but for the project I'm hoping to use this for, I'll have 30+ objects, some with more than 20 fields.

    I can appreciate the ease of testing since the view really has nothing to test, but if it means I have to write twice as much code, much of which is a simple copy....I fail to see how I gain.

    The gain is that your code is testable with MVVM.

    I've heard it said that unit tests are "the source of truth" for the codebase that meets and passes the tests. Take a bit to comprehend the mind-shift; unit tests are more important than the code that passes it. With this very different perspective, one where unit tests are the backbone of quality assurance and more important than the code it masters, then you can understand how one might construe your internal debate as missing the point. The value of MVVM is unit testing, the expense of writing the code to implement it is an acceptable cost of doing business.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.