Quick MVVM Design Question
-
I've done this both ways, but I'd like to hear what you guys do.... Bind The Entity Have the VM get an entity, or pass it in to the CTOR, store the entity to a property on the VM, and bind the View to the entity's properties. With this approach, the only way to 'undo' is to requery the data, but it's easier to set up and maintin, IMHO. Bind To VM Properties Have seperate properties on the VM for everything bound on the View. Load those properties from an entity. Then, when saving, create or update an entity from the VM and save it. To Undo, simply reload the VM's properties from the entity. But it's another set of properties on the VM mirroring those on the entity.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I've done this both ways, but I'd like to hear what you guys do.... Bind The Entity Have the VM get an entity, or pass it in to the CTOR, store the entity to a property on the VM, and bind the View to the entity's properties. With this approach, the only way to 'undo' is to requery the data, but it's easier to set up and maintin, IMHO. Bind To VM Properties Have seperate properties on the VM for everything bound on the View. Load those properties from an entity. Then, when saving, create or update an entity from the VM and save it. To Undo, simply reload the VM's properties from the entity. But it's another set of properties on the VM mirroring those on the entity.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
I always had the properties declared in the VM, loaded from the model which reflect a view from the database. However I have a tool that generates the code from the database to the model and a region in the VM so refactoring effort is minimal.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
I've done this both ways, but I'd like to hear what you guys do.... Bind The Entity Have the VM get an entity, or pass it in to the CTOR, store the entity to a property on the VM, and bind the View to the entity's properties. With this approach, the only way to 'undo' is to requery the data, but it's easier to set up and maintin, IMHO. Bind To VM Properties Have seperate properties on the VM for everything bound on the View. Load those properties from an entity. Then, when saving, create or update an entity from the VM and save it. To Undo, simply reload the VM's properties from the entity. But it's another set of properties on the VM mirroring those on the entity.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
The first approach is really a "cheating" MVVM approach. You might as well not bother having the VM in there at this point because your view is almost binding directly to the model with only the thinnest of abstractions sitting on top. One of the purposes of the VM is that it is there to act as a guard for your model; suppose that I have a requirement that a model can only be saved if field_A is set and then field_B contains a value from 0 to 10, but if field_A isn't set then field_B can accept anything from 0 to 30. The VM is the place to ensure that this guardrail is enabled; it ensures the model is always pure before you attempt to save it.
-
The first approach is really a "cheating" MVVM approach. You might as well not bother having the VM in there at this point because your view is almost binding directly to the model with only the thinnest of abstractions sitting on top. One of the purposes of the VM is that it is there to act as a guard for your model; suppose that I have a requirement that a model can only be saved if field_A is set and then field_B contains a value from 0 to 10, but if field_A isn't set then field_B can accept anything from 0 to 30. The VM is the place to ensure that this guardrail is enabled; it ensures the model is always pure before you attempt to save it.
Pete O'Hanlon wrote:
The VM is the place to ensure that this guardrail is enabled
Global validation rules should probably be enforced in the entity and the database as well wherever possible. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
The first approach is really a "cheating" MVVM approach. You might as well not bother having the VM in there at this point because your view is almost binding directly to the model with only the thinnest of abstractions sitting on top. One of the purposes of the VM is that it is there to act as a guard for your model; suppose that I have a requirement that a model can only be saved if field_A is set and then field_B contains a value from 0 to 10, but if field_A isn't set then field_B can accept anything from 0 to 30. The VM is the place to ensure that this guardrail is enabled; it ensures the model is always pure before you attempt to save it.
I use all "three"; depending on the situation. And sometimes all 3 at the same time. There's the POCO; no "brains"; just getters and setters. Then there are "is valid" getters, etc.; the "smart" POCO. Then there are the Observable collections of same; bound to a lists and views at the same time ... with the selected POCO showing in a view ... which could be controls on a map. Binding the POCO could be simple a DataContext assignment; or it is completely or partially aided by view getters into the POCO (view model). e.g. if I want to show "full name" and I have "first" and "last", the obvious thing is to make a "full name" getter ... in the POCO or in the view. Variants of the ToString() override. The list goes on. "Classic" MVVM is only one strategy ... and a very narrow one at that.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I've done this both ways, but I'd like to hear what you guys do.... Bind The Entity Have the VM get an entity, or pass it in to the CTOR, store the entity to a property on the VM, and bind the View to the entity's properties. With this approach, the only way to 'undo' is to requery the data, but it's easier to set up and maintin, IMHO. Bind To VM Properties Have seperate properties on the VM for everything bound on the View. Load those properties from an entity. Then, when saving, create or update an entity from the VM and save it. To Undo, simply reload the VM's properties from the entity. But it's another set of properties on the VM mirroring those on the entity.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
When I instantiate a VM, it typically instantiates the model on its own, which retrieves the data (from a database, xml, or json file). If the requirements call for modifying/saving the data, I keep the model around in a protected property inside the viewmodel. Most of the time, I set the data context to the form, and bind controls to the viewmodel(s) and various other properties. I don't think I've ever set the data context to a specific viewmodel because that just means more typing.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
