Does anybody know a useable MVC/MVP framework for enterprise WinForms applications?
Before there was User Interface Process Application Block for .NET. But it is not longer under development since Windows Workflow Foundation has been released (which also will be completely rewritten with .NET 4.0).
Maybe i am not up-to-date, but i seems to me like there is a gap at the moment.
I've always rolled my own - it's not really difficult and the more I am in 'control' of my codebase the better I feel.
I just wonder how an MVC framework would fit in with, say, CastleWindsor or the like?
This probably isn't the most helpful of answers but just wondering if you have already considered this option!
We use the Smart Client Software Factory from MS. It provides IDE integration, full MVC support and once you get over the concepts behind it is a very competent implementation. You can acquire it from: http://msdn.microsoft.com/en-us/library/aa480482.aspx
Microsoft has the Composite Application Block (CAB) for use with WinForms applications. While not technically an MVC/MVP implementation, it does provide nice separation between UI code and non-UI code: http://msdn.microsoft.com/en-us/library/aa480450.aspx
It is also fairly popular to just do it yourself without using any frameworks as long as you are comfortable with the relevant patterns. Jeremy Miller has an excellent series of articles on some best practices when taking this approach:
Build your own CAB Part #1 - The Preamble
Build your own CAB Part #2 - The Humble Dialog Box
Build your own CAB Part #3 - The Supervising Controller Pattern
Build your own CAB Part #4 - The Passive View
Build your own CAB Part #5 - The Presentation Model
Build your own CAB Part #6 - View to Presenter Communication
Build your own CAB - Answering some questions
Build your own CAB Part #7 - Whats the Model?
Build your own CAB Part #8 - Assigning Responsibilities in a Model View Presenter Architecture
Build your own CAB Part #9 - Domain Centric Validation with the Notification Pattern
Build your own CAB Part #10 - Unit Testing the UI with NUnitForms
Build your own CAB Part #11 - Event Aggregator
Build your own CAB Part #12 - Rein in runaway events with the "Latch"
Build your own CAB Part #13 - Embedded Controllers with a Dash of DSL
I didn't like Prism, CAB or SmartClient for being too complex and ended up rolling out my own implementations, in the end.
As time goes, some common patterns are emerging. These are get reused from an application to an application. Here is an example: DDD and Rule driven UI Validation in Windows.Forms with MVC.
I'm plugging my own framework : TrueView for .NET. It's based on DDD and the Naked Objects pattern.
At the very least, using it to create quick prototypes is a great way to get decent feedback from your business users.
All these standard frameworks are not suitable for large complex application developments and they assume that the displays will be static. I have developed my own as well due to the common requirement that the screen controls have to be dynamic, even the MVC/MVP patterns assume that the display will be static so when the fields diplayed in a control depend on what role a user has the MVC/MVP patterns are not suitable. I have developed a tool where you can build the screens from loading up the business objects and their properties into a database then the user just selects the objects and object properties she wants to display, a control can be made up of any number of control groups, each control group can contain any business object property, the business objects are generated from views by my Linq ORM. A control will therefore only display the fields of the control groups that a user has access to. You could also use Aspect orientated programming to provide the gule for the MVC pattern but when the displays have to be dynamic based on the role this overhead would probably add a little to much complexity and performance cost.
I am saying that the MVC/MVP patterns require that the required interfaces that the view must implement be known in advance, thus the actual view implements the view interfaces. Hence they are static i.e the interfaces have to be known in advance. It may be possible to make these interfaces as generic as possible but I suspect that some assumptions would need to be made. If the interfaces are made generic then this rather defeats their purpose of having an interface in the first place. By using the MVC/MVP patterns you are trying to reduce the complexity and allow seperation of concerns of the interactions between view logic and model logic and hence making them generic (if it can be done) does not make sense. In general having interfaces is nice if a system is really seperate from another system, however when the components of the system are so close together, i.e they are an intimate part of one system i.e in this case the UI component, then this extra partitioning of the system comes at a cost of flexibility. Can you explain why you disagree with me?
Hi guys,
very interesting answers. And I partially agree with alicat and I am wondering if alicat could hand out his framework to others. Because this excatly is the problem. If you end up writing your own implementation of common patterns you always have to keep it up to date in terms of documentation, samples and current technology. And for a company which isnt a techology provider this would create unpredictable costs and witout talking about missing skills to create and maintain such frameworks.
So even if the mainstream framework implementation coming from Microsoft or the Open Source aren't complete or are missing flexibility, it would be better then to extend those frameworks with ideas mentionned here rather than creating useless competition and wasting time by reimplementing the basics over and over again...
But I am still wondering if alicat could send me a version of his framework. I would take time to analyse it.
Thanks guys Happy Sunday Michael
As well as TrueView, there's also Naked Objects for .NET. This supports client/server mode and a web viewer (based on a Java equivalent viewer) is currently being ported.
As for which properties/actions are available for a given user/role, this is done dynamically in Naked Objects. There are three sorts of business rules preconditions that are supported: 1. is the member visible? 2. is the member usable? 3. is the change to the member (new property value or action parameter) valid? Or, more pithily: can you see it? can you use it? can you do it? The Naked Objects programming model lets these rules be specified both declaratively and imperatively.
Even if you end up wrapping your domain model in your own UI layer, I recommend you take a look at NO.
Cheers
Dan Haywood
author: "Domain Driven Design using Naked Objects", pragprog.com
I've used with success the following open source project to implement the MVP pattern in ASP.NET + WinForms + C#:
Take a look at my blog post which shows a complete ASP.NET Web Application sample: