View Model in WPF

CapableObjects forum

mtiede (2009-05-28)

Brian,

1. If your constructor has a single eco object, what do you do when the view is something like master detail?
2. What would be the datacontext in that case?
3. Where do you put functional code? For instance, if you had a function to filter the records based on a textbox value. Do you put that in the partial class?
4. How do you work with DataGrid?
5. For the DataGrid, since it wants an observable collection of objects that are IEditableObject, how do you handle that?
6. How do you handle the fact that the objects in the DataGrid have to have a default constructor with no parameters?

First I want to clarify that my ECO experience is using ECO with an ASP.NET application. My experience with WPF is with a custom persistence domain object architecture. I wish I could use ECO instead of this custom architecture as it would be much nicer, but as you all have probably experience what we want to use and what we have to use are not always the same. Smile

Although the persistence is completely different the WPF binding concepts are the same. WPF doesn't care what or where the object comes from for binding.

1. WPF has a very elegant binding mechanism for handling master detail on a view. You use a ContentControl for the detail and bind the detail object to the content property. Then set the ContentTemplate to a DataTemplate that contains the controls that bind to the detail object. The following rough example has a ListView for a master and a ContentControl to contain the detail. The ListView ItemsSource will be set to a property on the DataContext called Addresses. The ContentControl's content is bound to the selected item of the list view. So you simply create an AddressDataTemplate that has the controls to bind to the selected address. Note, I'm leaving less than characters out of post as the html does not like them.

ListView x:Name="lvAdresses" ItemsSource="{Binding Path=Addresses}">
...
/ListView>
...
ContentControl ContentTemplate="{StaticResource AddressDataTemplate}" Content="{Binding ElementName=lvAdresses, Path=SelectedItem}">

Where this stuff really shines is using a DataTemplateSelector. By using a DataTemplateSelector you can have different templates depending on what is bound to the Content. So if you had a list of different objects that you were binding to you can selected a different template view for each object. This is really slick once you get the hang of it.

2. The DataContext of your form is the base object that you will bind to. As you saw in the example above you can bind to any property of the DataContext. Mater of fact with Eco's special binding you can bind to the result of an OCL query.

3. Yes, I would put functional logic in the code behind partial class. I do try to avoid this as much as possible. For your example I might create a UserControl that performs filtering in the manner you described. I'd like to point out that views that are not data entry, but rather more functional, could use a separate class for functional logic. I would not call this class a view model, but rather a controller. I would write the controller to be view independent so it could be reused if need be. An example of this would be a view that performs searches for a particular object (ex. Person Object). If the searching logic is large and complex, I could create a SearchController to bind the SearchView to. This is what we did on the WPF project I am working on. Actually, we first wrote the search controllers in WinForms and when we made the switch to WPF we used the same controllers without one change. It worked out pretty good.

4. The DataGrid binds very similarly as the ListView.

5. The DataGrid also works with IBindingList. We are using BindingLists to bind to DataGrids. If I rememeber correctly, ECO collections implement IBindingList. I have not tried to bind an ECO collection in WPF though. I sure hope it works. Smile

6. IBindingList has an AddNew method. So I would assume the DataGrid would use this method if the collection implements IBindingList.

Regards,
Brian

Author	Message
mtiede	Posted 2009-05-28 00:42:05
Supreme Being Group: Forum Members Last Active: 2011-06-28 16:42:26 Posts: 487, Visits: 1 277 3 170	Can I do MVVM ViewModel in WPF using Eco technology? /mtiede Environment: Windows 7 Ultimate 64 bit Delphi 6 Rad Studio 2010 Enterprise with Prism 2011
	REPLY QUOTE LIKE 1
brian	Posted 2009-05-28 07:37:59
Supreme Being Group: Forum Members Last Active: 2012-05-01 21:02:15 Posts: 144, Visits: 421 940	mtiede (2009-05-27) Can I do MVVM ViewModel in WPF using Eco technology? I'm sure you could, but I would as the question: why would you want to? With WPF's robust data binding you can bind directly to eco objects with an elegant ease. Putting a view model in the middle will just cause you a lot of headaches. For example: Lets say you have a property on your view model that is populated or calculated from an eco object. You create a WPF view/window and bind a TextBox to the property on your view model. Now lets say you have another view/window with a different view model that uses the same eco object to calculate a different property. Now a user has both view/windows open and changes the value in one of them. The other view/window will not be updated with the change. You can make it work if you add the INotifyPropertyChange interface to your view model and listen to the property changes on the eco object to propagate the changes, but this is an incredible amount of work for zero gain. Just bind directly to the eco object and you get the automatic updates for free. The other problem with view models is they tend to get loaded with business logic. Since the nature of a view model is to facilitate building views, the view models tend to be tied to a specific view and also to a specific view framework (i.e. WPF). Naturally this is bad to tie your business logic to the view logic. Business logic belongs in the Eco Objects (i.e Domain Objects). If you are very disciplined by put all your business logic in the Eco/Domain Objects and use binding to bind the view controls to the Eco/Domain object, then there will be very little left to put into the view model. For the most part the only logic left is the glue logic for user actions like button clicks. My preference in WPF is to create CommandBindings in the XAML and implement the CanExecute and Execute in the code behind. It is important not to program business logic in these methods. Only put the glue logic to call into the Eco Object to do the action logic. Another useful thing I do when creating a view (i.e. Window or UserControl) is to make a constructor that takes the Eco/Domain object as a parameter for a constructor. In the constructor I assign the DataContext to the Eco/Domain Object. This is all you need to do to make the data binding in the XAML work properly. I also create a public property right next to the constructor to get the DataContext as the Eco/Domain object. This property can be used to fire the action logic for button clicks and the like. The following is an example of this: public PersonEcoObject { get { return DataContext as PersonEcoObject; } } public MyWpfPersonView(PersonEcoObject person) { DataContext = person; }
	REPLY QUOTE LIKE 1
mtiede	Posted 2009-05-28 15:40:32
Supreme Being Group: Forum Members Last Active: 2011-06-28 16:42:26 Posts: 487, Visits: 1 277 3 170	Brian, Thanks for the reply. For the most part, what you described as your practice is what I was originally thinking of doing. Then I was reading about the MVVM pattern and I wasn't sure if the VM part of that was what Eco provided or whether I should add the VM layer. With WPF, I really like the idea that the window/page/form can just have the UI with bindings to the data and nothing more (well events of course). And I like the fact that doing it that way allows the rest of the app framework to be tested with something like Nunit. So here are some more questions. 1. If your constructor has a single eco object, what do you do when the view is something like master detail? 2. What would be the datacontext in that case? 3. Where do you put functional code? For instance, if you had a function to filter the records based on a textbox value. Do you put that in the partial class? 4. How do you work with DataGrid? 5. For the DataGrid, since it wants an observable collection of objects that are IEditableObject, how do you handle that? 6. How do you handle the fact that the objects in the DataGrid have to have a default constructor with no parameters? /mtiede Environment: Windows 7 Ultimate 64 bit Delphi 6 Rad Studio 2010 Enterprise with Prism 2011
	REPLY QUOTE LIKE 1
mtiede	Posted 2009-05-28 15:47:13
Supreme Being Group: Forum Members Last Active: 2011-06-28 16:42:26 Posts: 487, Visits: 1 277 3 170	Brian, Oh, and also, if view model is not a good thing, why has eco added some beginning view model structure? What are your thoughts on that? See this post: http://www.capableobjects.com/apps/InstantForum414/Topic3255-4-1.aspx?Highlight=viewmodel /mtiede Environment: Windows 7 Ultimate 64 bit Delphi 6 Rad Studio 2010 Enterprise with Prism 2011 Edited 2009-05-28 15:48:07 by mtiede
	REPLY QUOTE LIKE 1
nagir	Posted 2009-05-29 03:14:49
Supreme Being Group: Forum Members Last Active: 2010-08-11 17:02:44 Posts: 338, Visits: 890 2 218	Hi, if view model is not a good thing, why has eco added some beginning view model structure? From my experience all the magic stuff just doesn't work in real projects. You always need a little thing that you cannot do. I find AutoForms and Eco Dubugger useful ONLY for administrative purposes. (I don't want to spend 20% of time implementing screens that users won't use but I still need those screens). I find automatic UI useless. It just never works for real users, they always want something custom. Thou might be good to show a prototype. So you will spend time to prepare prototype (with all the problems you posted in the other post), then time to implement normal screens (why not just do the former and once?). And as soon as I see "Object reference not set to an instance of an object" in simple situations. I fall back from it; it doesn't seem to be ready. ECO already has AutoForms (a little buggy, but it mostly do the job), ECO Debugger. This is sufficient for Back-Office/Admin usage. In my opinion, ECO should concentrate on real outstanding issues (especially querying abilities InPs) and not invent smartnesses that won't be useful for developers (FILL IN THE SURVEY). There are A LOT of OR/M tools on the market nowdays and ECO should become competitive in that area, which I think it hardly is. ECO does really good the UML part, but not OR/M. Cheers, Dmitriy. My Blog: http://dnagir.blogspot.com Edited 2009-05-29 07:26:48 by nagir
	REPLY QUOTE LIKE 1
brian	Posted 2009-05-29 07:38:06
Supreme Being Group: Forum Members Last Active: 2012-05-01 21:02:15 Posts: 144, Visits: 421 940	mtiede (2009-05-28) Brian, 1. If your constructor has a single eco object, what do you do when the view is something like master detail? 2. What would be the datacontext in that case? 3. Where do you put functional code? For instance, if you had a function to filter the records based on a textbox value. Do you put that in the partial class? 4. How do you work with DataGrid? 5. For the DataGrid, since it wants an observable collection of objects that are IEditableObject, how do you handle that? 6. How do you handle the fact that the objects in the DataGrid have to have a default constructor with no parameters? First I want to clarify that my ECO experience is using ECO with an ASP.NET application. My experience with WPF is with a custom persistence domain object architecture. I wish I could use ECO instead of this custom architecture as it would be much nicer, but as you all have probably experience what we want to use and what we have to use are not always the same. Although the persistence is completely different the WPF binding concepts are the same. WPF doesn't care what or where the object comes from for binding. 1. WPF has a very elegant binding mechanism for handling master detail on a view. You use a ContentControl for the detail and bind the detail object to the content property. Then set the ContentTemplate to a DataTemplate that contains the controls that bind to the detail object. The following rough example has a ListView for a master and a ContentControl to contain the detail. The ListView ItemsSource will be set to a property on the DataContext called Addresses. The ContentControl's content is bound to the selected item of the list view. So you simply create an AddressDataTemplate that has the controls to bind to the selected address. Note, I'm leaving less than characters out of post as the html does not like them. ListView x:Name="lvAdresses" ItemsSource="{Binding Path=Addresses}"> ... /ListView> ... ContentControl ContentTemplate="{StaticResource AddressDataTemplate}" Content="{Binding ElementName=lvAdresses, Path=SelectedItem}"> Where this stuff really shines is using a DataTemplateSelector. By using a DataTemplateSelector you can have different templates depending on what is bound to the Content. So if you had a list of different objects that you were binding to you can selected a different template view for each object. This is really slick once you get the hang of it. 2. The DataContext of your form is the base object that you will bind to. As you saw in the example above you can bind to any property of the DataContext. Mater of fact with Eco's special binding you can bind to the result of an OCL query. 3. Yes, I would put functional logic in the code behind partial class. I do try to avoid this as much as possible. For your example I might create a UserControl that performs filtering in the manner you described. I'd like to point out that views that are not data entry, but rather more functional, could use a separate class for functional logic. I would not call this class a view model, but rather a controller. I would write the controller to be view independent so it could be reused if need be. An example of this would be a view that performs searches for a particular object (ex. Person Object). If the searching logic is large and complex, I could create a SearchController to bind the SearchView to. This is what we did on the WPF project I am working on. Actually, we first wrote the search controllers in WinForms and when we made the switch to WPF we used the same controllers without one change. It worked out pretty good. 4. The DataGrid binds very similarly as the ListView. 5. The DataGrid also works with IBindingList. We are using BindingLists to bind to DataGrids. If I rememeber correctly, ECO collections implement IBindingList. I have not tried to bind an ECO collection in WPF though. I sure hope it works. 6. IBindingList has an AddNew method. So I would assume the DataGrid would use this method if the collection implements IBindingList. Regards, Brian
	REPLY QUOTE LIKE 2
HansKarlsen	Posted 2009-05-29 20:17:17
Supreme Being Group: Administrators Last Active: Yesterday @ 18:25:39 Posts: 446, Visits: 2 654 3 005	Why we do ViewModels in ECO: 1. I really think that will make you and me more productive. - No other reasons really. How? Using the ExpressionHandles, ReferenceHandle, VariableHandle etc lets you do the rendering part of Winforms, and also WPF (yes they work for WPF, we have added CursorManagerHandleWPF, but we have not spent time on bringing up the designers from WPF designer (other story really)). Using EcoDataSource you can handle serverside rendering of ASP.NET. - But is it REALLY an ideal situation to take model-info in the form of ocl and spread it out in many places like we do in all the handles and their columns? Sure you may only use default columns and nestings so you may not suffer from this. But having a transformation step between what you render (FullName) and your data (Titel FirstName Lastname) is actually very usefull. BUT I can use derived attributes for that you may say, and sure you can, but it does not necessarily remove the good thing of having a rendering layer between the model and UI. This is more clear now than ever before; the WPF rendering model allow for true separation between UI and model. This may very well lead to a situation where you expose an idea for the UI that you hand over to designers to work on, while you continue to work on your model.... When you work on the model you will rename things, make things more detailed etc -> you have a different model than the one you gave the designers. In this case it would be perfect if you had a rendering layer that states how you transform from the model to the UI-model - the ViewModel. What ViewModels in ECO are is the declaration of this transformation, what the transformation is and how far it goes - nothing else. ViewModels in ECO are NOT AutoGenerated forms Nagir. Promise (almost). BUT when we have these named model transformations available in runtime it sort of opens up new possibilities. Instead of having to use 3 to 15 different handles on your form to make the master detail and comboboxes work as you want, we can use one ViewModel. Thats why we did the ViewModelUserControl for Winforms, that reads the viewmodel and creates all the handles needed to fullfill a ViewModel. And sure you may not want to spend time on the UI-parts, even if you are able to plug and override it to get your own stuff in there. But you may still want to use the Datapart of it, to avoid the Handle mess. In WPF where the ability to style the UI is endless, the ViewModel based user controls shows great promise to actually solve most of your needs, leaving more time to the complex stuff. Having worked this way for a couple of weeks I am pretty confident that this is good stuff. My vision is to provide ViewModels, then have different tools that work on these in runtime like the WinForm-UserControl, same for WPF, Silverlight, ASP.NET. Why not produce DTO's from the ViewModel (since it describes the transformation it would be perfect for this). (Oh, before I get you started Pete, No I have not forgotten about our discussion about the naming of the ViewModels, but signs point to that the name stays) /Hans Karlsen
	REPLY QUOTE LIKE 1
mtiede	Posted 2009-05-29 22:23:53
Supreme Being Group: Forum Members Last Active: 2011-06-28 16:42:26 Posts: 487, Visits: 1 277 3 170	But the version I have doesn't let me use ViewModels with WPF. I assume the version you have does? When will that be available? /mtiede Environment: Windows 7 Ultimate 64 bit Delphi 6 Rad Studio 2010 Enterprise with Prism 2011
	REPLY QUOTE LIKE 1
Jonas Hogstrom	Posted 2009-06-01 23:26:47
Supreme Being Group: Administrators Last Active: 2010-11-30 13:17:13 Posts: 1 230, Visits: 1 382 7 954	The ViewModel is very much work in progress. The build that I published a link to yesterday contains everything that was implemented by then. More has been added today and will be in next build. /Jonas Hogstrom [CapableObjects]
	REPLY QUOTE LIKE 1

CapableObjects forum

View Model in WPF

View Model in WPF

Similar Topics

Reading This Topic