Presentation Model - Winforms
-
Hi, i'm looking for a way to bind a BindingList to a grid... (allow adding a new row in the grid). If i'll use BindingList, i know it will work... but binding to he ViewModel allows me to add additional presenation logic to the class. How did you solve this? Thanks in advance, Erik.
-
Hi, i'm looking for a way to bind a BindingList to a grid... (allow adding a new row in the grid). If i'll use BindingList, i know it will work... but binding to he ViewModel allows me to add additional presenation logic to the class. How did you solve this? Thanks in advance, Erik.
Hi, First I implemented a bindinglistview which inherits from the BindingList and implements all necessary interfaces such as IEditableObject, etc. From there I used this in a custom collection that takes care of the Adding New logic. All of this came from the Data Binding with C#2 book but I cannot remember the author at the moment. Great indepth discussion in a single chapter on how to bind with objects. It also works well with the Interface during design time. Happy Coding
-
Hi, First I implemented a bindinglistview which inherits from the BindingList and implements all necessary interfaces such as IEditableObject, etc. From there I used this in a custom collection that takes care of the Adding New logic. All of this came from the Data Binding with C#2 book but I cannot remember the author at the moment. Great indepth discussion in a single chapter on how to bind with objects. It also works well with the Interface during design time. Happy Coding
Thanks for the helpful reply! =) I've explored this subject some more, and came across the CSLA.NET framework, As it seems the framework implementation does exacly that =) I'm still learning it, but it looks promising... Did anyone use this framework and implemented the Presentation Model pattern??? It seems rather cumbersome to wrap the CSLA entities with ViewModels, because them the ViewModel will have to implement all the interfaces and forward any calls to he CSLA entities... (And of course the ViewModel will have additional logic to help support the UI and DataBinding) BTW, If i'm not using the Presentation Model Pattern, and I have this rule for example: The row of a customer in a grid must be green if the customer ordered more than 10 items, at a price higher than 20$. If i'm using Presentation Model, then my customer's ViewModel will have a property OrderedMoreThanTenItemsAt20DollarsEach (for example), which will implement this logic and the view will use DataBinding to bind the rows color property. How will i implement this using the Supervising Controller pattern? (I guess passive view will just iterate through the rows in the grid). Thanks in advance, Erik.
-
Thanks for the helpful reply! =) I've explored this subject some more, and came across the CSLA.NET framework, As it seems the framework implementation does exacly that =) I'm still learning it, but it looks promising... Did anyone use this framework and implemented the Presentation Model pattern??? It seems rather cumbersome to wrap the CSLA entities with ViewModels, because them the ViewModel will have to implement all the interfaces and forward any calls to he CSLA entities... (And of course the ViewModel will have additional logic to help support the UI and DataBinding) BTW, If i'm not using the Presentation Model Pattern, and I have this rule for example: The row of a customer in a grid must be green if the customer ordered more than 10 items, at a price higher than 20$. If i'm using Presentation Model, then my customer's ViewModel will have a property OrderedMoreThanTenItemsAt20DollarsEach (for example), which will implement this logic and the view will use DataBinding to bind the rows color property. How will i implement this using the Supervising Controller pattern? (I guess passive view will just iterate through the rows in the grid). Thanks in advance, Erik.
The CSLA Framework from Rocky has been around a long time. Rocky has updated this for many years and a lot of companies use it. My understanding is that it is very good. There are other frameworks as well that might be used such as Smart Client Software Factory, Web Client Software Factory, ASP.NET MVC and the brand new PRISM for WPF and Silverlight. Personally, I have been sticking to the Microsoft Patterns and Factories. Then my model, my presenter, my view and/or controllers can be reused between them. All of these have things in common. The model, the view and the presenter or the controller. I personally like MVP since it truly encapsulates the actions, rules, transitions and translators into a reusable framework that can be used and easily adjusted as requirements change. If there is one thing for certain in this world - requirements change as the users or management see things evolve. The ability to know where to go to make these changes without Spagetti Coding is crucial to success. It appears that you have a good handle on the tiers here and their requirements. So here is my take. This is only my take and not a definitive answer. So if it is usable then hey use it, if not applicable to your case, file it away for later. The supervising controller is used to centralize the methods between views. All events that can be shared should be fired up to this controller and the controller in turns then fires commands back to interested views. It is very useful for keeping the views of data synchronized on the same class. So supervising controllers listen to events and fire commands to controllers which in turn fire the view events. Now you have a loosely coupled set of views that can be reused between modules without having any dependencies to any one parent container. The supervising controller handles the work and the actions, the view is merely a container with very few methods and the controller for the view has specific methods and interfaces to make the view do things. The controllers talk to the model and obtain most of the data then rearrange it as necessary using LinQ to Objects or if you are using generic list then use the predicates to handle the where clause etc. All views in turn should handle the same interface so the controllers fire things in a coordinated fashion. It keeps you from getting confused as to what to do. Over time you will see exactly how to do this and it will become automatic. Some of the model patterns that I use are the abstract factory pattern for the repository obj