What is going to happen with UIP?

Guess what. I started getting this question every month, then every week, then every day… now I get it every hour J, through different means: e-mail, blogs, e-mail threads I get included, communities.


So, I figured it would make sense to publish a clear statement and be a little bit more transparent.


The first half of the year 2006 was really dedicated to the Smart Client offerings: Desktop and Mobile. You probably noticed that already.


Now that we shipped both Software Factories, the team is focusing almost exclusively on the web space and a key deliverable we are currently planning is migration guidance for UIP. That is migration content for users currently using UIP on .NET 1.1 that want to move their application forward to ASP.NET  2.0 and  probably using Workflow Foundation.


The complete deliverable for the web space will most probably be very similar to the rest of the factories from the content perspective (How-tos, Guidance Packages, a Reference Implementation, etc.). UIP migration will be a specifically called-out content though.


At this point we are in the initial planning of the project and in the process of collecting feedback from you guys. Anything you would like to share with us, let us know!!


One of the things I’m working on right now is a (hopefully) short list of the most frequent and complex challenges if Web App Development that then we will post as a (short and sweet) survey for you to answer. In the meantime, if you have the time to write me an e-mail with what your experience has been and where you’d like us to invest, please do so! And don't forget to set priorities.


Also remember, don’t send me code. Send me a description of your problems and what you’d like us to solve instead, and stay tuned to our communities (like UIP)


Last but not least, UIP is still supported of course as any other patterns & practices offering.

Comments (23)
  1. Recently I asked you all for your suggestions on what we should include in Enterprise Library for .NET…

  2. Himanshu R. Swami says:

    It would be helpful if there would be some convergence between UIP and CAB – they seem to be complementary in some respects and overlap functionality in some respects – some sort of integration capability and insights to the same would help for those very heavily invested in UIP but would like to take advantage of the CAB to modularize parts of the UI (and other aspects of the application as well).

  3. Greg Hayes says:

    Concerned about path for Win Forms apps built on UIP.  Are there any plans there?

  4. Derek Greer says:


    I’ve used the UIPAB version 2.0 to facilitate the UIP layer of a Web application I’ve been developing for a little over a year, and I have quite a few ideas I’d like to inject as input for the next version.  It might be more appropriate to send detailed feedback through email, so I’ll just list a summary of a few ideas here.

    First, my number one desire is to see an MVC/MVP framework which doesn’t mandate the use of Tasks to function.    If the concept of Tasks is to be maintained in the next version, I’d like to see them be optional.

    Second, I’d like to see the next version be able to support Web applications whose underlying architecture is composite in nature.  My application’s architecture is very similar to the CAB, consisting of a main Web application framework “shell” which centrally manages authentication and navigation and provides module installation capabilities.  Each module of my application is a discrete unit of functionality (possibly developed by separate teams) and maintains its own configuration files (e.g. ~/Config/ShipModule/ship.config).  Each module specifies its own navigation graphs, views, etc.  I’d like to see the next version support different configuration sources allowing multiple “modules” to co-exist within a single Web application, each configuring their own UIP layers.  

    Also in support of composite based Web applications, I’d also like to see further abstraction in the navigation model to allow one module to register to handle another module’s navigation events (think “Navigation Broker”).  I envision something similar to the CAB’s Event Broker service in that one module could register to fulfill a navigation event raised by another module.  The event could be registered to allow only single subscribers or multiple subscribers.  Single subscribers might be used in the case where it makes sense to allow only one entity to fulfill the request (i.e. navigationEvent://MyModule/BrowseAddressBook).  Multiple subscribers could be processed in succession in use cases which allow other modules to extend an established workflow at a specific point (i.e. “navigationEvent://MyModule/PreCommitProcessing” or “navigationEvent://MyModule/WizardPreComplete”).

    Also, rather than focusing only on UIP concerns, has there been any discussion of going the route of creating a “Web Composite Application Block” which fulfills the same design goals as the CAB for Web applications?

    Derek Greer

  5. Matthew Dennis says:

    Most of the web applications that I design and write are intranet interfaces to business applications and processes.  As such, I find the UIP invaluable in allowing me to prototype with the client alternate workflows and removing the business logic and data access from the UI.  This allows me to make dramatic changes to the UI and/or workflow with little or no change to the controller and data components.

    I think that a WebView for the CAB that used Atlas for highly responsive, modular interfaces would meet most if not all of my needs.

    Of course, the ASP Membership, Personalization and Theming features should be exposed in a manner consistent with the rest of the Factory.

  6. Dmitry says:

    I find that UIP works pretty well in .NET 2.0. With a couple of adjustments to the code though. The only annoying thing is that it is using Data Access Block from the previous version of the Ent Lib and of course there is no suport as of yet for the new .NET Framework 3.0 (formely known as WinFX), which is understandable since this is still work in progress.

  7. Brian says:

    Let me start by saying the first UIP was gold to the project that used it correctly.

    Now let me say the rest.

    To be honest this scares me.  I was glad to see that Microsoft had apparently let it out to pasture.  The whole MVC/MVP thing scares me.  A lot of what I feel, and see, that is trying to be accomplished is the re-use of the same business logic and same GUI (whether aspx or winforms) across applications, even though I think the original goal was to manage workflows.  And this is what I mean by it being ‘gold’ to the projects who used it correctly.

    First, when you look at Smalltalk80 and the original MVC pattern it was more of a hardware pattern than anything, the way I read the history of MVC I didn’t see much worry of workflow.  Using a traditional NTier architecture alleviates having business logic in the GUI and has been defacto for years, and using the GoF Template pattern gives you the code reuse of GUI objects in the ASP world where the template is a user control and the page contains the specific algorithms that the template looks for (which usually just calls a method on the associated business tier object – acts as a proxy) – there is an article about this on my blog.   I think some sort of inhertance would give you this in Winforms…I’m not a Winforms guy though so I don’t know, but these are the things I’ve mainly seen the UIP used for.

    The one thing you do get from the UIP that I haven’t mentioned up unitl now is workflow, and I think what was intended by the UIP originally, and a nice feature to have.  But I’d really like to see a survey of how many people in actuallity change the workflow of there application often enough that the level of effort to implement the UIP, and all the extra moving parts, would make it worth it.  Myself personally, once the application reaches it’s first production build has rarely had a workflow change, and when it has it has been the addition of a new web page that requires a recompile anyway – there’s no advantage to all of these configurable settings.  Further more I think there are other GoF patterns that might handle this better; possibly.  I’ve rarely needed to worry about workflow once the program was written so I’ve never investigated.

    Again, the idea behind the UIP I think is well intended and well recieved in a ‘very, very good’ shop, and I won’t say that have the state persistance built in isn’t a nice feature, however it becomes a burden when the UIP is being used for a single view process because it is being used as a silver bullet to handle ALL navigation in a application; it leads to overly complex code that is horrible to have to maintain (especially when they’ve extended it) – I speak from inheriting such projects.  And while certianly the UIP is like any program; garbage in-garbage out, the guidance of when, where, how, and when not to, where not, and why not to, just isn’t out there as well as it should be.

    I think that really, the first thing that needs to be done is to step back and ask what the problem that is trying to be solved is.  And then ask if MVC, originally a hardware pattern (to the best of my knowledge), is the right answer.

    I am not against a new UIP, as I said, I think the first UIP was worth it weight in gold; when used properly. However, for this same reason, I am firmly against a new UIP that doesn’t include a very detailed best practices with it.

    You would think that and a statement that says ‘this isn’t intended to be used for all projects or all parts of a project – it is not a silver bullet’ wouldn’t be needed; but the copy and paste plug and play programmers of today don’t like to know the history or the details; they just see something that they think can magically do what they want it to do and it’s a buzz word, so they use it without understanding the problem in front of them or what problem the library they just downloaded was intended to solve.  Of coarse this is more of community problem and would easily be solved if everyone just read the Pragmatic Programmer and read the Circles and Arrows section over and over.

  8. Tamal Saha says:

    1. App.xml need to be invisible from the user. Probably including it as a dll will be helpful.

    I don’t want the user to change the xml file and create problems.

    2. Should be integrated with Enterpriselibrary2006.

    3. "Enterprise lebrary configuration" like xml writer will be helpful in writting app.xml file.

    4. XML based form generation should be included to generate some basic custom from.

  9. Derek Greer says:

    "… I’d really like to see a survey of how many people in actuality change the workflow of there application often enough that the level of effort to implement the UIP, and all the extra moving parts, would make it worth it."

    The concept of managing workflows is what I believe makes the UIPAB more difficult to work with than other MVC frameworks I’ve seen which focus more on just providing abstraction between the View and Controller logic.  This is why I’d like to see the next version provide a MVC/MVP implementation which doesn’t require the use of Tasks to tie a group of Views specifically to a workflow.

    As far as the original intent of the MVC being to solve a hardware problem, I haven’t gathered that from my readings.  It may very well be that Smalltalk in general was more intimately associated with its hardware which might have affected its MVC implementation, but I believe the overarching intent of the MVC pattern was simply to decouple the model, view, and controller components of an application.  I think the principal of “separation of concerns” is a valid endeavor for even the simplest of applications because you never know when a simple application will need to evolve into a more complex one, or whether you will have wished portions were more reusable in the future.

    I’m a bit torn between my recommendations for the next UIPAB.  One the one hand, I’d like to see an easier to use MVC-based application block which allows ASP.Net developers to separate controller concerns in a way more natural to ASP.Net development, but on the other hand I’d like to see a complete Web version of the Composite Application Block.  Perhaps the P&P team can create both in such a way as the Web Composite Application Block utilized a Web-based MVC application block.

  10. James says:

    I am new to Application Blocks, and the documentation for how to use the application blocks requires genius to understand. Is is possible to write some walk throughs? (eg. HelloWorld????)

  11. Brian says:

    "I am new to Application Blocks, and the documentation for how to use the application blocks requires genius to understand. Is is possible to write some walk throughs? (eg. HelloWorld????)"

    There are actually some out there, but they are far from real world.  Brian Noyles (spelling?) did a demo in 2004 that he included some sample apps with.  Look on MSDN events.

    "but I believe the overarching intent of the MVC pattern was simply to decouple the model, view, and controller components of an application"

    This is typically approached with N-Tier logical architecture, which scales very well with a N-Tier physical architecture.  I typically have a 5 tier system…Presentation (HTML/Javascript), UI (Code behinds), Business (Business Model/Rules/Validation), Data Access (using my own version of SqlHelper like set of classes…but factory pattern using dependancy injection so that I don’t have to recode when we switch from Oracle to SQL, or IBM DBW to SQL…which I’ve been a part of something simliar to that before), and finally the Data Tier which is SQL server or Oracle or whatever.

    This architecture also blends well when moving to frameworks such as Rocky Lhotka’s C# business objects which is probably one of the better enterprise level business modeling fraweworks…IMO.

    UIP just has too many parts IMO, and MVC has the seperation of concerns, but it’s real easy for a junior to misinterpert where the lines are drawn…with traditional N-Tier logical modeling the lines are more clear and when you have to go to N-Tier physical architecture it’s a pretty smooth transition.

  12. bi-ker-shi says:

    I had some issues when upgrading a WEB UIP 1.1 application to use AJAX controls (Infragistics specifically). The XMLHTTPRequest’s get intercepted and fire events in the code-behind before the UIP block has properly initialised and set up the State.

    I had to write custom modifications to the UIP block to work around this issue.

    I have actually delivered 5 commercial applications using the UIP Block for 5 unrelated clients. One of these actually made very good use of the Navigation, but only because the client had written a specification composed of a very large number of simple screens linked by hard navigation logic.

    When I have control over the appearence I tend to write much more complex screens that require less navigation. Thus I see the Controller State engine being very useful but only in a minority of applications.

    If we are using AJAX then it should be possible to make the WEB forms work like your CAB, i.e. partition the page into a number of frames with custom controls rolling in and out and the Frames controlled by the State Engine. This could of course be done without AJAX, but the very high frequency of post-back’s would drive the users crazy.

  13. Sam says:

    I am new to UIP and CAB. We are starting on a project, and we are evaluating both UIP and CAB. I still have not been able to figure out the difference between UIP and CAB? When do we use UIP and when do we use CAB

  14. bi-ker-shi says:

    UIP came before CAB and had a version for both win forms and web forms. Currently CAB is targeted at Smart Clients – Win Forms using Web Services. Currently UIP will not work in ASP.NET2.

    UIP has views (forms=aspx pages or windows) and Controllers=.NET classes. UIP has a concept of tasks, a related set of views with managed navigation and retention of State between them. The controllers manage task State, Navigation and a delegation layer to whatever the Model View Controller sits on top of.

    CAB partitions a form into a number of panels and smaller components called winparts that roll in and out of these. The winparts are typically built independently and usually simply have a number of controls like grids, combos, text boxes etc. These tend to retrieve and update data via Web Services automatically.

    Some of the parts may contain controls like a tree control and are responsible for which winparts get displayed in th other panels.

    Maybe the easiest thing to do with UIP is to make it work with VS2005 and then leave it there. I envisage that given the visual inheritance in ASP.NET2 (Win Forms has always had visual inheritance) something could be done here as well. I have some issues with the Session Moniker that I will discuss in a separate post.

    Making CAB work on top of ASP.NET2 looks quite complex and possibly not a good fit but worth doing.

  15. I think CAB and UIP suck!

  16. Cory Cundy says:

    There has not been a post here in almost a year. Are there still plans for more an updated version of UIP, migration guidance and a reference application?

  17. Hi Cory –

    Yes, the UIP scenarios are covered now by the Web Client Factory and the "Page Flow App Block" that uses Workflow Foundation to drive UI workflows.  

  18. Siva says:

    Do we have a migration guidelines/guidance for the existing customers who are using UIPAB?

    Your response is highly appreciated.

  19. The Web Client Software Factory has specific guidance for UIP users. Check: http://www.codeplex.com/websf

    And in particular: http://www.codeplex.com/websf/Wiki/View.aspx?title=Page%20Flow%20Application%20Block&referringTitle=Application%20Blocks

    There’s one Quickstart that covers migration from UIP to WCSF through a sample:

    "Migrating from the UIP Application Block and Page Flow with Shopping QuickStart"

    Hope this helps


  20. Joe into pace <a href= http://joe-pace.barerube.cn >sheet Joe pace</a> [url=http://joe-pace.barerube.cn]sheet Joe pace[/url]

  21. Pradip says:

    So is that means UIPAB has been completely replaced by WCSF & SCSF? I am developing a WPF application. Should I use SCSF?


Comments are closed.

Skip to main content