New Posts New Posts RSS Feed: View Model architecture
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

View Model architecture
 Post Reply Post Reply Page  <12
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
BillG View Drop Down
DevForce MVP
DevForce MVP
Avatar

Joined: 05-Dec-2007
Location: Monroe, MI
Posts: 233 		Post Options Post Options   Quote BillG Quote  Post ReplyReply Direct Link To This Post Topic: View Model architecture
    Posted: 24-Sep-2010 at 1:25pm
So the ViewModel calls the CustomerRepository class and retrieves the customer. What if I also need a list of offices, trade codes, statuses, etc. Do I create a separate repository for each of these. Should I have a equal number of repositories for all my classes that handles the CRUD methods?
 
Bill
 
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 24-Sep-2010 at 10:37am
The ViewModel could be seen as a wrapper around the model elements that are exposed in the view. In many of our examples, we only present a single model element.
 
But the ViewModel is not just a wrapper. It maintains LOGIC and STATE for the VIEW that it supports. It is UI aware without being bound to the specifics of the View.  For example, the VM could receive and handle the "NEXT ITEM" request from the View. The VM doesn't know if the request was a result of a button click, link click, scroll, page-landing ... doesn't know and doesn't care.
 
The View has no idea whether the move to the next item will be allowed or what might be going on in the background. That's the VM's job. The VM could decide that the user should not move from the current item. Or it might decide to save changes to the current item first. Or it might present a confirmation dialog. Or it might send a message to the world that the user is moving to a new item.
 
The VM is responsible for all of these potential actions in response to a user gesture. The View shouldn't make such decisions.
 
And your Model - the Business Objects - don't make these decisions either! They don't know about users and moving from one item to another. They don't know when to save or not to save. They don't send messages to the UI; they don't even know that there is a UI.
 
The VM is task oriented. The VM says "I support my View by telling it what it should present and what the user can do within this View. I will handle all user requests from my View ... typically by delegating to other classes that carry out my instructions."
 
No, the VM is never an entity. If I understand properly, it won't be your "former EventObject or B.O." either
 
In sum: the VM is far more than a friendly facade over the Model or its entities.
 
It's worth reading about MVVM elsewhere. You might look at MVVM Light for a simple but useful example of the pattern.
 
--
You wrote: "In my VM I instantiate a EM (_mgr) and building a query. "
 
I do that in demos but not in real code. I have a firm rule: the VM never talks directly to an EntityManager. It always talks to an injected helper class that is responsible for acquiring the entities. That helper class is often known as a "repository".
 
The repository has access to the EntityManager and actually issues the queries. The repository exposes a method (e.g. "GetCurrentCustomers" ) that encapsulates the query. The VM would call upon the repository to fill a target collection (e.g., "customers = repository.GetCurrentCustomers()" ).  The View binds to this VM collection.
 
My examples assume a synchronous data access approach for simplicity of exposition here. You'd need an asynchronous interface for a Silverlight client.
 
The separation is critical for testable and maintainable code.
 
It is also necessary to pour the query results into a collection that supports the View. The EntityManager returns a kind of List. In WinForms, WPF, or Silverlight you likely want a different kind of list ... one that is both richer and more specific to the binding framework ... like ObservableCollection<T>.
 
HTH 
 


Edited by WardBell - 24-Sep-2010 at 10:39am
Back to Top
Peer View Drop Down
Newbie
Newbie
Avatar

Joined: 31-Aug-2010
Location: Netherlands
Posts: 15 		Post Options Post Options   Quote Peer Quote  Post ReplyReply Direct Link To This Post Posted: 24-Sep-2010 at 5:01am
I'm working  on my first self-made DevForce driven application implementing the VM concept.

The VM is obvious a mediator between the view an the model, right ? I would prefer a generic VM (like the prismExplorer)  which drives an entity in the entitymanager and provide it with navigation events and other standard factorymehods. Specific Viewmodels are subclassed from the generic ViewModel. The ViewModel is actualy a wrapper around an entity.

Why this architecture? We are used to have an Entity ebedded in a BO class and provide the entity whith generic behaviour or even specific behaviour (adding rules, defaul values, pre-post crud hooks) These BO's could relate to other BO's in a parent-child relation. In this way cascading event were fired surch as Save-delete. Transaction behaviour was activated in the parent BO so all the child BO's travelled inside the Parent Transaction.

BO's could be added  at designtime to a class (an Event Object) to perform bigger tasks, e.g. the complete functionality of an orderentry module. No UI dependencies at this level.
*--
Here is my point / question:
Should the new viewmodel be our former Eventobject or Our former BO. ?  i.o.w. Is the new ViewModel an (single)Entity driver or a class containing specific tasks (e.g.  all the Order entry functions) ?
I hope you get my point. 

*--
a second question is more technical:  
In my VM I instantiate a EM (_mgr) and building a query. The result exist as a collection in the query (Entity Job = _mgr.Job)

Why should I create a second collection in my VM ( Jobs = _mgr.job),  Why not use the _mgr.job collection for binding ? Right now I have to sync the two collections ( _mgr.EntityChanged += ...)
Back to Top
 Post Reply Post Reply Page  <12

Forum Jump Forum Permissions View Drop Down