Tom Hollander's blog

patterns, practices and pontification

UIP - how did that work out for you?

UIP - how did that work out for you?

Rate This
  • Comments 10

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.

  • 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.
  • The biggest flaw in UIP web is in how it does not handle a session timeout very well. UIP reads from session when it wires up the view and controller, and all that happens before page_load and in a place I can't catch it. All you get at this point is a null reference exeption. It didn't take me too much time to get caught in this trap, and that makes me wonder how well UIP web is really tested and under which scenarios.

    I never managed to pass state from one navigation graph to another. It seems like the code for doing that is missing, that is, the method is there, but it's empty.

    I did not find the UIP to be unit test friendly. I could not create a standalone view, nor connect a view to a controller under test.

    Everything which can be configured should also be possible to do explicitly in code. The web.config gets too large. A gui tool to manage the configs would be nice, too.

    It's pretty meaningless to pass a generic controller to a view. The view can't use it anyway without casting. And then the view has to know which controller is configured in web.config, which render the use of a config file pretty meaningless. You can't just switch controllers or views on the fly.

    UIP works against the ASP.NET architecture. It tries to do something in a way I think ASP.NET was never meant to do.

    Web Forms != Win Forms. Those are two different platforms with different architecture. Using same UI code on both is a disaster waiting to happen. Or did it happen already?

    UIP also seems half done. I should not have to write a ton of supporting code to have a framework working. Isn't the point of a framework to save work and code?

    It's hard to use and hard to understand. The web samples which follows are just lame at best. They do not describe how to do anything vaguely complex.

    I also felt that UIP put a restriction on my choices. It was no longer easy to exploit all ASP.NET features.


    What do I want from the next UIP?

    1. A team which stays present. Don't publish a new framework and vanish from the planet's surface.
    2. The team should stay alert to the community and answer any questions.
    3. Test then ship!
    4. Separate Web UIP from Win UIP. They are not the same. The GUI and workflow will differ at some point.
    5. Make it complete. Please don't make me to add tons of supporting code.
    6. Document it with relevant samples, not just silly simple ones. Please don't make me guess on how it's working.
    7. Develop it in a Test Driven fashion. Then you know how to develop it so we can use TDD too.
    8. Don't force us to use certain ASP.NET features. ViewState and SessionState should be optional.
    9. Don't restrict us from certain ASP.NET features.
  • 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.
  • Agreed on the separation of the state management and front controller pattern implementations. As a part of the front controller, its very important to support all common web paradigms. Things such as:

    - Navigation by url, so some sort of auto-activiation of a view/process is required along with enforcement of transition rules
    - Terminating one process by navigating to a view that is a part of another process should not cause a redirect by the browser if possible

    It would also be helpful to make the model of serial execution of a single task as simple as possible to use since that is the most common scenario.

    The MVC pattern is useful for almost every type of application, so focusing on the simple stuff first and the complex uses later would gain critical mass most quickly.
  • 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?
  • I have worked with UIP v2 for more than 6 months in a big ASP.NET application divided in 3 sub-Applications. This sub applications are related each other and share the same datamodel and
    Business objects.

    At first, we faced some difficulties implementing UIP:
    - It is not so easy to install and to manipulate;
    - Add some code to make it work properly;
    - Magic of the navigation is a lure;
    - Configuration is boring..

    Nonetheless, we found benefits using UIP:
    We decided to use it in collaboration of the ACA.NET Validation framework(from Avanade). Of course, we spend time on setting up this block, on building our own layer upon UIP, on producing early documentation for the developers but the result is brilliant.

    We use the Controller to provide data to the model for the view or to process the model given by the View. We validate our model in the view thanks to ACA.NET Validation framework. Everything is tending to configuration (we configure the rules we like to see in our model), that is quite helpful now we are in FAT(Functional Assembly Test) and now that everything needs to be changed or readjusted.
    To conclude on the benefits, UIP really permitted us to rationalize the development of the Presentation Layer by helping to provide rigour and boundaries to developers and to development.

    My list of disadvantages/Improvements:
    - Configuration should be taken by a kind of "Configuration Manager";
    - This crazy Back button is still a pain;
    - The sate should be clearer. Actually, we don't know what to put exactly in this state and what we have to do with volatile information.
    - No simple bridge from a user control to a view and a Controller;
    - The navigation concept should be more flexible (the UI will probably help).

    Another thing that is quite annoying is that a view can only have one controller. If the view wants to use one or several processes available in another controller, we have:
    - To duplicate code :(
    - To put the method in a base controller :\
    - To create a static method :/

    At the end, we have few controllers with many methods and only one state with a lot of information from different scopes..
    What about allowing the view to use the controller it likes or defined for it! We can also create the notion of contract (a view can use this method of this controller etc) or a step ... quick ideas ...

    Hope it helps.
    - UIP rulezzz -
  • 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
  • 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
  • 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?
  • The same old Microsoft problem...The documentation is completely lame. Examples are all overly-simple toys.

    I also agree that it seems half-done. Right off the bat, you can see the xml code documentation is incorrect dozens and dozens of times.

    Very difficult to find support from MS or elsewhere, as I'm sure everyone reading this is experiencing.

    I like the DAAB and EMAB, but this one has me uneasy. I think it's clear that this one is a bit of a dud.

    On the other hand, it HAS put me on the whole MVC concept, which I didn't know much about. I suspect I'll be stealing from this AB to make my own simplier version.

    Regards, BPM
Page 1 of 1 (10 items)