The Build Your Own CAB Series Table of Contents

Yes, this is overdue.  Here is an introduction and table of contents to my “Build Your Own CAB” series of blog posts on designing WinForms applications.  You’ll see nothing here about user experience and not much WinForms technology.  That stuff is covered quite well in a hundred different places.  This series is about code.  How to write it, how to write less, how to test it, and how to structure it.  And there is code in user interfaces, no doubt about that.  Code that’s complex.  Code that changes every time you’re foolish enough to ask an end user how they like it.  Code that’s hard to test if you’re not careful.

I’m still working on the series, so check back here occasionally for updates and new downloads.  After I finish posting the menu state series I’m going to take a break for a while, but it’s for a good cause.  The most persistent complaint throughout the series is that it’s not clear how all the pieces fit together.  Understandable.  At the same time that I’m writing this series I’m also working on my OSS StoryTeller tool that includes a sizable WinForms client.  Last week I scrapped about half of the StoryTeller UI code so I could go back and incorporate the ideas that I’ve explored through “Build a CAB.”  I can say without a doubt that I’m the one person who’s learned the most from “Build a CAB.”  What I’m hoping to do is use the StoryTeller UI code to demonstrate fully working screens from end to end.  The beauty of using OSS code for examples is that the code is automatically available for download.

I’ll finish before the end of the summer, I promise.  Just set a bookmark to this page and I’ll keep updating it as the series expands.  At the end I’ve committed to gathering all this stuff up into a single, printable PDF for download.
 

 

Downloads

Soon…

 

Table of Contents

There’s an extended introduction below.

  1. How I got into this mess – Look for the section “Microsoft, OSS, and the Patterns and Practices Team”
  2. Preamble
  3. The Humble Dialog Box
  4. Supervising Controller
  5. Passive View
  6. Presentation Model
  7. View to Presenter Communication
  8. Answering some questions
  9. What’s the Model?
  10. Assigning Responsibilities in a Model View Presenter Architecture
  11. Domain Centric Validation with the Notification Pattern
  12. Unit Testing the UI with NUnitForms
  13. Event Aggregator
    1. Event Aggregator with Generics
  14. Rein in runaway events with the “Latch”
  15. Embedded Controllers with a Dash of DSL
  16. Managing Menu State with MicroController’s, Command’s, a Layer SuperType, some StructureMap Pixie Dust, and a Dollop of Fluent Interface
    1. MicroControllers
    2. Boil down the “wiring” to a Registry
    3. The Command Executor
    4. The Main Players
    5. Testing through the UI – Forthcoming
    6. Subcutaneous Testing – Forthcoming
    7. Creating the Application Shell – probably a couple posts
    8. Wiring the Components with an IoC tool – Forthcoming, but I may push this off into late summer
    9. A Day in the Life of a Screen – by popular demand (gripe), let’s look at a couple of complete screens through their entire lifecycle

     


    Introduction

    In building enterprise software systems I’ve often observed a feeling that building the actual User Interface is less demanding or important in terms of design compared to the backend.  We worry quite a bit about the appearance and the usability of the User Interface, but how about the code structure of the UI itself?  In my experience, UI behavior changes more often than anything else and generates a much higher defect rate.  Several years ago I briefly used Use Case Points as an estimation technique.  One of the features of this technique that caught my eye at the time was how it treated user interface features.  Any feature that included an interactive user interface was automatically given a higher modifier of effort than the same size feature that only dealt with other computers.  In that technique it was a given that interfacing with a human was more complex than interfacing with other code.  My point being here that user interface development is complex and we need to take it seriously.

    A couple years ago heavy clients were out of style due to well-founded concerns over deployment and support issues.  Lately, or at least for me anyway, heavy clients seem to have made a comeback as the newer .Net technologies have alleviated the deployment concerns somewhat.  Instead of dying away, we’re building more complex WinForms user interfaces than ever before.  There’s a lot of talk about building “composite” applications that can quickly host multiple, logical applications or applets in the same application shell.  We’re trying to build applications that can be easily extended without ripping up the existing code.  We’re sold on Test Driven Development, but the user interface has remained one of the last uncharted territories for automated testing.  The traditional approach towards building user interfaces in the Microsoft is to fire up the designer and pump energy and effort into it until it works.  That has to change.

    At DevTeach 2007 I gave a talk called “Put Down that Wizard!” with a subtitle “Design Patterns for Maintainable WinForms.”  By and large, the talk was about how to code and design a WinForms application.  I discussed design patterns for assigning screen responsibilities, screen synchronization, and issues that effect testability of user interface code.  I was fairly happy with the way the talk went and the feedback overall, but a particular comment from an attendee caught my eye:  “the content was obscure.”  The criticism itself wasn’t bothersome in and of itself, but the fact that these patterns were considered “obscure” definitely bothered me.  Designing software is largely an exercise in determining the responsibilities of the code and assigning these same responsibilities to different modules of the code.  How you assign, or fail to assign, responsibilities has a great impact on the maintainability of a codebase.  Patterns like Model View Presenter are a reoccurring recipe for assigning responsibilities in a user interface.  These patterns weren’t created or invented, they were discovered by practitioners who began to describe the structures that worked (or didn’t work).  If we’re going to build and evolve more complex user interfaces, we can’t blow off the internal structure of the user interface code.

     

     

    What’s this series about anyway?

    At DevTeach 2007 I was part of a panel on the tenuous relationship between Microsoft and the Open Source community.  At some point in the panel discussion and the resulting blog discussions afterward, we set off an argument about whether or not the Composite Application Block (CAB) framework was necessary or even valuable for building larger, maintainable WinForms applications.  My point of view then, and now, is that understanding the core concepts and patterns is the first step.  I don’t think you can use the CAB effectively unless you understand the underlying patterns.  On the other hand, if you understand the underlying patterns and design forces, you can quite efficiently and effectively do your own thing.  Either way, you want a strong core of design principles. 

    User interface technologies change.  I’m sure it’ll take a while, but WPF screens will eventually eclipse WinForms and who knows what’s over the horizon.  The specific knowledge that you carry around about WinForms widgets will be obsolete soon.  I think the Microsoft community stresses API knowledge too much and core design principles too little.  When I switched jobs last fall I knew I was going to need a better foundation on WinForms, so I bought and read one of the more popular books on WinForms by a Microsoft luminary (and I say this without any irony).  I read the book and it presented the technology behind WinForms very effectively.  The wizards and designer support was well covered, but the book didn’t address the issues of maintainability and testability in WinForms development.  There wasn’t a single mention of any kind of View/Controller separation in the entire book.  That’s a huge gap in knowledge, and one I hoped to help fill by writing this series. 

    The way it’s unfolded, this series isn’t really about replacing the CAB with your own Model View Presenter pattern.  It’s just the things you can do to make a maintainable WinForms architecture — with or without the CAB.  A large chunk of maintainability for me is creating code that’s easy to test with granular unit tests, and you’ll see this desire for testability permeating the entire series.  Despite rumors to the contrary, it is possible to Test Drive WinForms development, but you testability has to be a first class design goal.

    One of the other points I wanted to get across in my DevTeach talk was that oftentimes a code-centric approach can accomplish user interface tasks faster and with less duplication than using the designer.  I’m just now starting to explore some of these code-centric solutions through the later posts involving Fluent Interfaces.  The designer is great for laying out the look and feel, but we can’t allow the designer to be our architect.  I don’t think WinForms is a bad technology at all, but it’s deeply flawed in the sense that it does not lead you into a maintainable structure.  The designer makes it relatively easy to crank out user interface code, and that’s what it’s doing behind the scenes, but some judicious code-centric design can eliminate duplication and reduce the overall effort.  Maintainability is your job, not the designer’s.

     

    So hotshot, you think you can build a better CAB?

    No, I don’t, that’s not my point.  My point was just that if you were well armed with an understanding of the underlying design patterns and motivation that you could happily evolve your own application specific framework that would better fit your application.  Part of that belief is that building a framework is much simpler in this day and age of Dependency Injection tools.  Today, you can pull one of a couple different Inversion of Control / Dependency Injection tools off of the shelf that are all more powerful than the limited ObjectBuilder inside the CAB.  Then again, I’m the progenitor of one of those tools, so my opinion might be somewhat suspect.

    And yes, to be honest, like many developers there’s an inner demon inside of me that arrogantly believes he can build a better [insert name of framework] and is just dying to prove it. Begone inner demon, begone!

    About Jeremy Miller

    Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
    This entry was posted in Build your own CAB, Design Patterns, StoryTeller. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • http://zacherygaines.webstarts.com/ KadeemFulton

      India, due to its cost-effective services, has emerged as a best model for the Offshore software development services.

    • http://jonsonbettly.wordpress.com/ ScottWorkman

      Presently, globalization is pressuring lots of firms to boost their competition frequently. Offshore software development not merely lowers internal expenses but in addition provides high quality service.this one is nice.

    • Anaya Upadhyay

      Great information…

    • http://www.keystrokesrecorder.org keyboard tracking software

      This is an informative article.

    • http://www.recoversms.com sim card recovery

      WOW! What a great Blog!

    • http://www.keystrokecapture.ws Lokesh Ruhela

      I like this comments in blog!

    • Johan Samyn
    • Eyal-Shilony

      Hopefully this series of posts will continue someday…

      Do you think you will ever compile it into a PDF ?

      Best Regards.

    • Salam

      Source code of the examples:

      http://code.google.com/p/buildyourowncab/source/browse/#svn/trunk/src

      Just wanted to do something good in return to the great posts…

    • Raul Lorenzo

      This documentation is fantastically great!!! It helps me to clear my doubts about different approaches with MPV/MVC which makes me confused a lot.
      When will be available next chapters?

      Anyway, thanks for publishing this knowledge

    • Raúl Lorenzo

      This documentation is fantastically great!!! It helps me to clear my doubts about different approaches with MPV/MVC which makes me confused a lot.
      When will be available next chapters?

      Anyway, thanks for publishing this knowledge

    • Florian Fanderl

      Hey :) great stuff in here! Thanks for all those nice concepts as I’m pretty new to “real” OOP.
      I’m currently developing my first project using this technique and I’m pretty convinced that this is by far the best attempt to develop new software.

      The only thing that makes me sad is, that you haven’t finished all topics. I’d love to read the rest of this Post :)

      Thanks anyways and keep the stuff coming!!!!

    • http://www.alachisoft.com/ncache/cab_index.html,www.alachisoft.com/ncache/cab_index.html Prjesh Anand

      CAB (Cashing Application Block) in the Enterprise Library is been implanted to simplify development tasks but due to it’s in process and standalone behavior it reduces the performance of the application which is not in most case tolerate able. This drawback can be overcome by using third party integrations including NCache which is free available and can be tested for the performance and scalability

    • http://www.alachisoft.com/ncache/cab_index.html,www.alachisoft.com/ncache/cab_index.html Prjesh Anand

      CAB (Cashing Application Block) in the Enterprise Library is been implanted to simplify development tasks but due to it’s in process and standalone behavior it reduces the performance of the application which is not in most case tolerate able. This drawback can be overcome by using third party integrations including NCache which is free available and can be tested for the performance and scalability

    • Ben Arroyo

      “… so I bought and read one of the more popular books on WinForms by a Microsoft luminary (and I say this without any irony)…”
      What book is that one?

    • maridob

      Great articles! where is the sample code now?

    • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

      @Samnang:

      Book, 1st Qtr 2010 maybe.

    • http://tech.wowkhmer.com Samnang

      Great series, waiting for a complete pdf format + code?

    • http://loadingvault.com/index.php engine

      To everybody that attended one of my talks at DevTeach this week. All of the materials are now online

    • http://www.e-zest.net/offshore_product_development.html Offshore Software Product Development

      Great stuff… I am waiting for new article on this subject…

    • David Mc.

      Love love lovin this series Jeremy!

      I think your Table of Contents and the individual articles numbering systems are starting to get out-of-sync though…

    • Blake

      Great series! Eagerly awaiting the next installment!