UIP - how did that work out for you?
The User Interface Process Application Block (UIP) is an interesting beast. I know it's got a strong following based on the number of people who have asked me when this block will be given the Enterprise Library treatment. On the other hand I've also spoken to a number of people who have tried to use the block but eventually dismissed it as it was deemed to complex for their application. Now this isn't a bad thing on its own - the last thing we want is for people to use blocks where they aren't appropriate. However if too many people come to this conclusion then it indicates that we've missed the mark.
I came to p&p relatively recently from consulting land, and I never came to use UIP on a project, although I did work with a UI framework with a similar architecture (i.e. a state machine governing the navigation). Although this project made it to production, I came to the conclusion that it would have been much better to use a much simpler "pure ASP.NET" architecture. Now I do think the UIP has a really nice architecture (especially for drawing on a whiteboard), and there are definitely projects that benefit from the formal separation of the UI screens from the navigation process. But I do wonder whether this represents closer to 70% or 10% of enterprise ASP.NET applications.
So what does the future hold for UIP? Really, it's up to you. We've already decided (based on extensive feedback) to split the block into separate deliverables for Web and Smart Client development (see edjez's blog from last year for more). The latter is being delivered into the upcoming Composite Application Block, while the former lies in my (capable? you decide) hands. Our current priority is to move the Enterprise Library v1 blocks to Whidbey, but we promise to get to UIP Web as soon as we can. We are looking at ways to make UIP more relevant to more applications - our current plans are to evolve UIP to focus more on providing a solid MVC implementation. The navigation graph / state machine would stay, but more as an optional component than the central theme. And of course all new blocks will adhere to the new Enterprise Library specification, including support for the configuration tool and new documentation format. But we're far from having the specs locked down. Please let me know if you've used UIP v1 or v2, what worked for you, what didn't, and whether you think the proposed direction is the right one or if you have any better ideas.
PS... in cased you missed it, we've posted some new sample configuration providers (app.config, registry, SQL server and Mvp.Xml serialization) to the Enterprise Library community. Also Scott has posted a new installment of his tutorials on extending the Configuration Application Block.
This posting is provided "AS IS" with no warranties, and confers no rights.
Comments
- Anonymous
March 01, 2005
Actually I'm in a special situation: I have worked with UIP for 6 months to build a framework for windows based applications in a financial institution but I have not yet used it to build a real application. I'm trying to do it right now while fixing some real world issues with my framework.
UIP alone is hard to sell, what the future programmer-user sees is a huge configuration file (partially simplified thanks to the UIP Attributes) and code scattered in views, control views and controllers. I had to add a powerful state machine that provides an event programming model at the controller level plus a lot of code to support the main form, the toolbars, etc.
The result is interesting, from the user perspective, because you mainly need to override functions in your views and controllers to do the job.
The conclusion is that it is not so easy. I wrote a "starter guide" showing how to write a very simple application using the framework, but it has more than 40 pages, that is still too much. I like the separation between presentation and process, I like the potential reuse of the non UI part (although not yet tested), I like the event-driven layer I built on top of UIP but I'm afraid of its overall complexity. I really wonder how the average programmer will manage to use it.
An UIP based appliation also has a potential I did not explore yet: its testability. In theory you should be able to write unit tests that test nearly everything but the UI events. If you can show people how to write these tests it can be a very good argument for the UIP.
My conclusion is that the UIP alone is not usable, you have to package it with other blocks and templates to that programmers will feel the advantage to use it.
Actually I think that two blocks are missing: The "Windows Application Application Block" and the "Web Application Application Block", and UIP will be a block nearly hidden in these blocks. Programmers will be, like monsieur Jourdain in Molière, UIP programmer without knowing it.
Hope it helps, and thank you for your work. - Anonymous
March 01, 2005
The comment has been removed - Anonymous
March 02, 2005
The concepts behind the UIP block - MVC, state management and the front controller are all brilliant in theory but slightly harder to achieve cleanly in practise (although kudos for the first two versions as I've learnt a lot from them).
I generally work on web based UIs that require some form of user process to achieve the goals of the application i.e. Enter some data, get some information back, verify the information and add some more then finally achieve what you set out to do. Being able to encapsulate this kind of workflow logic into a single controller class for a process is great, one place to look at when trying to figure out how something works and one place to integrate workflow and business logic. I think it would be fair to say a number of the developers I work with are also sold on the idea of an MVC style implementation for the web.
What makes the UIP block so unweildy is that it tries to provide the MVC implementation, the Front Controller implementation and the state management engine in a tightly coupled block. Almost every instance where the UIP has been used in a project where I work, it has been hacked to make it fit.
What would I like to see from the next UIP block? A clear separation between the MVC implementation, the state management implementation and the front controller implementation as this would make understanding and using the block much simpler in the long run. - Anonymous
March 04, 2005
The comment has been removed - Anonymous
March 09, 2005
I agree with Thomas Eyde's comments. I went into UIPAB with the intent to use the navigation graph in a web application. But it is enormously complicated, there are very few good samples on configuring the beast, you're still writing XML by hand, and worse, it doesn't handle back buttons properly.
At this point the theoretical advantages don't outweigh the practical disadvantages of writing piles of code to do something that was pretty easily done before with a few Response.Redirects.
Especially since it doesn't yet work with the Enterprise Library, which I'm now wading into instead in the hopes of realizing some of those advantages.
Regarding the EL, what is the recommended way to strong-sign the assemblies and put them in the GAC for a web application? - Anonymous
March 14, 2005
The comment has been removed - Anonymous
March 16, 2005
I am building asp.net applications since about 3 years using standard asp.net architecture. I have built a class library for database connection and data retreivel(retreiving datareader and dataset objects). In this way I have seperated data layer. I wanted to use MVC architecture for more seperatioan and modularity of code. So I started looking out for some good articles and "how to" tutorials. At this point I came across this "UIP application block v 2.0" with documentation from Microsoft.For testing purpose I am trying to move some of the web pages from my working application to this architecture, but it seems too much complicated. I wish documentaion contained some type of step-by step guide how to create this type of UIP based web application. There is so much unexplained code in "UIP application block". Does any one know such step-by step guide or turtrialon this.
Thank you.
Bharat(a very eager user of UIP Applicayion Block).
bpgadhia@yahoo.com - Anonymous
March 16, 2005
I have been working with UIP v2 for the past few monthes in order to build the first in a series of windows forms apps and in the end I have to say that it helped a lot.
Of course I have some complaints (no specific order)
1) Documentation is somewhat sketcky. Often had to dive into code to find my answer.
2) Examples are not that great. Need to be real world examples and follow recommended practices.
3) Testing. Found a couple cases where some functionality was not completely exposed (i.e. Passing TaskHolderArguments object to UIPManager Start methods.)
4) Configuration is a nightmare. This definately needs to be rethought. EntLib's Configuation AB would probably help with the config files but those files are still holding too much. Attributes could help in some cases..
5) Strong-names assemblies. I understand MS doesn't want to distribute the Application Block code with the strong names to avoid user modified code clashing in the gac. Makes perfect sense, however, the binaries copies we get from MS could and should be strong named.
My two cents worth.
Bill - Anonymous
March 17, 2005
I am currently using UIP v2.0 is a web based applciation. This is the 2nd project I'm using it. The most common problems I encountered are about the configuration file and the lack of create a drawing of my navigation graph. I think if I had a designer that I can "draw" my navigation graph and not dealing with the config file will ease the work with UIP.
We had a lot of problem to "fit" the navigation graph to work both on web and WinForm so I think it is a good choice to split it to two seperated application blocks. However, how the things will be when Avalon is released? - Anonymous
March 24, 2005
The comment has been removed