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
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 Topic: View Model architecture
    Posted: 27-Oct-2010 at 5:57pm
I just added my "Bad Golf" example to the DevForce Cookbook that demonstrates some of my thinking on these subjects. I've opened a Forum Topic for it here (http://www.ideablade.com/forum/forum_posts.asp?TID=2271&PID=8947#8947).
 
Please take a look and let me know what you think THERE rather than here.
 
Let's consider this thread closed in favor of the "Bad Golf" topic.
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: 17-Oct-2010 at 10:34am
Thanks for the insights, Peer. All good sense.
 
I try hard to distinguish my recommendations from my "rules". I do not have a "rule" on whether a Repository should be oriented to a single root aggregate entity (Peer's approach) or to a module-based collection of collaborating aggregate entities (the approach I recommended).  I don't have a "rule" about whether a Repository should be allowed to save or not (I have done both and probably will again).
 
Many roads can get you home.
 
I will tell you when I think a road leads through the swamp.
 
As Peer says, you have to accumulate experience and read what other folks are doing.
 
All the best,

W
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: 13-Oct-2010 at 12:06am
From my perspective I use  1 repository as a wrapper for 1 entity.  This is not wat Ward suggested in this post before... The Items and CurrentItem properties of he repository gives me a clean and consequent binding interface. I'm in the middle of a test-evaluation process and can not share code with you at this time. I think your discission is about 1 or more entities in one repository.

  • for 1 entity per repository: (my way)
     The hard way is to make 1 generic class
    A more simple way is to make a baseclass and subclasses for yout entities

  • for more entities per repository (Ward's preferred way)
    Make a class containing 1 or more observable collections, create factorymethods which you can fire from you viewmodel

  • Add commands to your viewmodel which you can bind to xaml (MVVMlight V3.  ->commands ) works fine for me .

I'm a newbie to .net, sl, MVVM and all the other techniques an it takes a lot of effort to make these concepts working so far. Just keep reading and looking for demo's. I realy do  recommend the MVVMlight toolkit  to you, Ideablade have some demo's how to use them in your application. It takes som time to read all this, the guy who wrote this toolkit has a great video on his site.

Best regards,
Peer
Back to Top
alindzon View Drop Down
Newbie
Newbie
Avatar

Joined: 28-Jul-2010
Location: Toronto
Posts: 31 		Post Options Post Options   Quote alindzon Quote  Post ReplyReply Direct Link To This Post Posted: 12-Oct-2010 at 2:44pm
I really appreciate the feedback BillG and Peer.  As a complete beginner at MVVM and Devforce I am trying to picture what the XAML, viewmodel, and repository all look like in one example where the UI has a datagrid which implies the filters and sorting are being controlled by the user in real time.
 
I think the choice of which datagrid is not really relevant, since they all have filtering and sorting built in.
 
And alternatively a scenario where the query is fixed and the parameters have been passed into the viewmodel when its called into being.  For example product details being requested by a product grid, could launch a product details view.
 
And finally, what about data you want to persist for as long as the application is running, for example I have all the states/provinces in a table to allow two letter abreviations to be used but related back to the full name. 
 
I would love to see any examples of how this is done in repository, viewmodel, and view so that it all works without loading the whole database in the client.
 
I am trying to wrap my head around how one designed repositories, viewmodels, and views in these cases.  Please tell me if I am getting it or if I am confused.
 
My understanding is the repository should be somewhat abstract but tailored to meet both the needs Peer outlines as well as some more tailored queries like BillG outllines.  I also understand certain rules and business logic can be placed in the repository, such as the code necessary to assing a unique ID when a new item is created as well as key data validation.  One recommendation I have heard is to have one repository for each major class of data.  For example customers and ship to addresses might share a single repository.
 
The viewmodel controls the views access to data exposed by the repository.  Its the viewmodel that glues the two together and controls the interaction, and contains more specific businss rules, and that understands errors and results generated by the repository. 
 
And finally the view itself just controls the presentation and manages the interaction with the user, and lets the viewmodel do the real work.
 
 
 
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: 12-Oct-2010 at 9:42am
Thank Bill for your suggestions :).

I'v implemented  a similar strategy in my project  but different in a important way. The repository class is an abstact class which I can instantiate in my viewmodel. The result is an observable collection  (Items)

for example:
Companies = new Repository<Company>(_mgr); 
Projects = new Repository<Project>(_mgr);

the result are two object whith an observable collection items ...
Companies.Items[]  and Projects.items[]
default properties also  Companies.CurrentItem and Project.CurrentItem  to which the selecteditem attribute in Xaml can be bound. 

I inject the where clause with  a lambdaexpression:
Projects.Where = p => p.companyid == Companies.CurrentItem.id;

This scenario works perfect for me :)  but maybe not for everone ....

Best regards, Peer

 
Back to Top
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 Posted: 12-Oct-2010 at 9:11am
Here is an example of a method in a class called MembersRepository that retrieves members from the members table based on a query. In my ViewModel class, I have a method called FetchMembers that calls this method. This method returns the members back to a Member ObservableCollection object in the ViewModel. The ViewModel as a result of the INotifyPropertyChanged interface automatically binds the Members collection to the appropriate control which in my case is a datagrid.
 

private readonly LaborWareEntities mgr = SingletonEntityManager.GetManager();

public ObservableCollection<Member> Members { get; private set; }

public ObservableCollection<Member> GetMembers(MemberQO q)

{

Members = new ObservableCollection<Member>();

var query = from Member in mgr.Members

where Member.LastName.StartsWith(q.LastName) && Member.FirstName.StartsWith(q.FirstName) && Member.Status == q.Status && Member.Office == q.Office

orderby Member.LastName, Member.FirstName

select Member;

query.ExecuteAsync(op => op.Results.ForEach(Members.Add));

return Members;

}

 

You mention about being for use in raddatagrid or a similar control. Your repository class does not konw anything about your Views or whats on those views. It is strictly for retrieving the data from the datasource.
Back to Top
alindzon View Drop Down
Newbie
Newbie
Avatar

Joined: 28-Jul-2010
Location: Toronto
Posts: 31 		Post Options Post Options   Quote alindzon Quote  Post ReplyReply Direct Link To This Post Posted: 03-Oct-2010 at 7:37am
Does anyone have any example of a repository that supports get and save and viewmodel, so I can see what one looks like that is properly constructed?
 
If it happens to be a for use with raddatagrid or a similar control even better.  I am trying to understand how it all fits together.
 
Thank you in advance.
 
Back to Top
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 Posted: 28-Sep-2010 at 2:14am
So I would have a MemberRepository class that would have a GetMembers() method along with helper objects that would populate dropdowns etc such as GetStatuses(), GetTradeCodes(), GetJobs() etc.
 
I would have a MemberUnitOfWork class that would have CreateMember(), UpdateMember(), SaveMember, and DeleteMember.
 
I have a MembersListView which displays a grid of all members depending on search criteria and a MemberView should displays information about a paticular member. Is it ok to have both of them share the same ViewModel and that ViewModel would access the MemberRepository and MemberUnitOfwork classes.
 
 
Back to Top
hijaggu View Drop Down
Newbie
Newbie
Avatar

Joined: 26-Sep-2010
Posts: 21 		Post Options Post Options   Quote hijaggu Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2010 at 3:29pm
Thanks a lot ..I appriciate your help :)
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: 27-Sep-2010 at 3:25pm
@hijaggu -  I would delegate wiring of a list manager to the repository. This is a perfect example of how the Repository can help you.
 
Could you put that into GetCurrentCustomers?
 
If the filter changes from one usage to another, could you change the signature to GetCurrentCustomers(filter)?
 
If you want to separate managed from unmanaged customer lists, could you create a GetCurrentCustomerAsManagedList(yourCustList, filter) method?
 
Perhaps you want to keep the notification apart from the Repository ... maybe put it in a RemoteStorageChangeNotificationService. Give that a method to register (and unregister?) the list and filter. That service can have access to the gateway.
 
The objective is to restrict the number of EntityManager access points to give you better control, testability, and quality.
 
Obviously you don't want to hamstring daily development. But ... really ... do you want the kind of list manager registration code you showed lurking in all of your ViewModels? That's seven tricky lines of persistence that have nothing to do with presenting information in the view. ViewModels don't care about that stuff.
 
Better to delegate to a service (the Repository or NotificationService) that is responsible.  I believe your code will look a lot cleaner and you'll sleep better.
 
HTH
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: 27-Sep-2010 at 3:12pm
@paul - The large model question is an important one ... and one I address with heat and enthusiasm. Just not here :-).  Try this forum post.
Back to Top
hijaggu View Drop Down
Newbie
Newbie
Avatar

Joined: 26-Sep-2010
Posts: 21 		Post Options Post Options   Quote hijaggu Quote  Post ReplyReply Direct Link To This Post Posted: 26-Sep-2010 at 1:21pm
Hi ,
 
I like the idea and advantages of implementing repository. Though I see some chanllanges while implementing in real world application. Say for example , how to keep list of customers supplied by repository to VM  up-to-date in below case.
 
customers = repository.GetCurrentCustomers()
 
we are using SQLDependancy to get notifications if there is any change in Customer table and to keep local cache up-to-date. If there are couple of inserts / updates / deletes on Customer  table , we just fetch the delta records ( recently added / modified / deleted records since last refresh ).
 
 
One way of keeping customers list up-to-date with the cache is using EntityListManager like below but then we are breaking encapsulation and accessing EntityManager _em1 out side the repository ,
 
 
var filter = new Predicate<Customer>(
 delegate(Customer anCustomer) {
   return anCustomer.City == "NewYork"; });

_CustomerEntityListManager =
 new EntityListManager<Customer>(_em1, filter, null);

bool refreshListWhenPlacedUnderManagement = true;
_employeeEntityListManager.ManageList( customers ,  refreshListWhenPlacedUnderManagement);
 
Would you please suggest me if there is any soluton for such chanllange ?

 
Back to Top
paul View Drop Down
Newbie
Newbie


Joined: 16-Sep-2010
Posts: 19 		Post Options Post Options   Quote paul Quote  Post ReplyReply Direct Link To This Post Posted: 25-Sep-2010 at 4:39pm
I hate to be the guy that asks "when" but... I am starting a large new SL app and I am trying my hand at DevForce. I am coming off a major WPF application that used CSLA. I would love to see the concepts you described previously in a real-world application. At this point I would love to see your post above sprinkled with code examples. Your spin on the repository pattern intrigues me since I am old asp.net hack.

I am also studying the limits of EF4. My old WPF/CSLA app used LinqToSql (L2S) for the DAL. We broke the L2S models up based on our form structure/unit of work since our database has almost a 1000 tables and views. As you can imagine we have hundreds of L2S models. I don't regret the decision, it works well for that project. Researching EF4 it is basically understood that VS or maybe EF itself can't handle very large EF models. I am not sure what people consider large? 10, 50, 100 entities? I have been reading and watching your posts on the subject and I am considering this: Our new application will have a very large SQL Azure DB. We are planning to have multiple SL XAPs loaded on demand broken up by the business verticals we want to attack; CRM, payroll, AR, AP, etc... One EF model for each business verticals with either one matching DevForce domain model or domain models broken down further by form/unit of work. Currently I am worried with having multiple domain models for one EF model that I might have to replicate business logic within the domain models. Like if I have a rule for the customer object but that object is in many domain models. I haven't found a good way to handle that yet.

I am not looking for free enterprise application design, I am willing to do the footwork but I want to make sure I am going in the right direction. Easier to turn around now than 12 months down the road.

Thanks...
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: 25-Sep-2010 at 12:41pm
Guess what I'm working on :-)
Back to Top
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 Posted: 25-Sep-2010 at 8:56am
I wish Ideablade had a sample Silverlight or Wpf application that illustrated all these patterns (MVVM,Repository,Unit of Work etc.).


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 5:55pm
Great question.
 
My answer: try to write one repository that exposes the methods you need for the module. If the module needs "offices, trade codes, statuses", then the Repository gets them.
 
 
Why: I orient the Repository to the specific needs of a module ... and strive for ONE repository per module. I drive the Repository API from the needs of the module and the scenarios it supports.
 
----
 
Discussion:
 
Your repository won't expose "Get..." methods for all of these types. That's a bad idea. Many of these types are just reference entities that should be held in cache and accessed by your primary business objects via navigation.
 
For example, "Order.OrderStatus" could return an "OrderStatus" reference entity. If I don't need an OrderStatus method on my repository, why bother? I just need to be able to get to OrderStatus codes from my Order.
 
Therefore, I won't have a "repository.GetOrderStatus()" method ... or one for TradeStatus or any other of these auxilliary reference entities. Instead, my repository will have an initialization moment during which it acquires the reference entities en masse.
 
Aside: you often need to populate ComboBoxes with reference entities. When that happens, you can write a generalized reference entity retriever for this purpose. Maybe you write a "service" that provides codes by name or type. Such a service would delegate to a repository to do the work. Of course the repository would not have a separate method for each code type.
 
The repository could offer "GetActiveCustomers" and "GetCustomerOpenOrders" methods if those had business domain meaning and if (really only if) one of the module's ViewModels or some other module service component needed such methods.
 
Ward's rule: Do not anticipate. Write a repository member "just-in-time" ... when some module component actually needs that member.
 
A corollary of this approach: "IRepository<T>" is never useful.  I never seem to find a generalization that pays off.
 
Btw, you don't write CUD methods on a repository. I don't even have a "Save" on my repositories. "Save" is a method on the UnitOfWork container (I call it a "gateway"). The UoW actually owns my EntityManager which it shares with the Repository.
 
Does that seem like too many moving parts? Why would I separate the thing that saves from the thing that gets? Because I have many screens that can only get and present. They aren't allowed to save. "Save" is a potentially dangerous operation. I don't want my ViewModel to be able to save unless it is supposed to be able to save.
 
By separating the "Saver" from the "Getter", I can safely give the "Getter" (the repository) to all kinds of ViewModels ... and never lose sleep over one of them trying to Save. I give the "Saver" (the "Gateway") only to those VMs that really, really need it.
 
Such separation is overkill for small modules but is a lifesafer in bigger ones. When I start to have a lot of screens - a lot of V/VM pairs, I work hard to make sure that all my parts stay small, simple, and do only what they need and should do.
 
Hope that makes sense to you.
 
----
 
"This doesn't sound like the repository pattern I've read about"
 
Most discussions of the Repository pattern are conducted by Web developers who are trying to satisfy a single web request. A proper web request controller maintains no state between requests and each individual request isn't going to need much in the way of entities. A web developer doesn't cope with a variety of long-lived entities. That's why you see them talk about IRepository<T> and about "aggregates".
 
On the other hand, RIA and desktop applications maintain lots of state for prolonged periods of time. A given module instance will juggle a great variety of entity types at any one time. 
 
Desktop and RIA apps have a completely different paradigm  - one that requires a completely different take on the repository pattern.
 
That said, the fundamental insight - encapsulation of queries and cached business objects within a "Repository" component that reifies the container metaphor - this is as useful to us as it is to web developers.


Edited by WardBell - 24-Sep-2010 at 6:13pm
Back to Top
 Post Reply Post Reply Page  12>

Forum Jump Forum Permissions View Drop Down