Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Rik on Design Patterns

Rik Bardrof, one of the senior developers at Xclaim, recently gave a presentation to the Syracuse .NET Developer’s Group. I was in town, so I captured the talk.

In it, he covers a few patterns/principles we use extensively in our products:


This entry was posted in architecture, patterns, video. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

14 Responses to Rik on Design Patterns

  1. Mario says:


    My apologies. The source code is available at the bottom of Rik’s blog post entitled “Tech Valley Code Camp”.

  2. Dave Laribee says:

    @Brian – No worries, man. I just had “one of those days” myself.

    @Mario – I’ll send the request along to Rik.

  3. Mario says:

    Is there going to be a link to the source code?

  4. Brian says:


    Your right. I was in a pissy mood and shouldn’t of been so pissy here. I appologize.

    My mood is a result from spending a lot of time lately recovering the titanic because someone thought more was better and seemed to put Enterprise Patterns in a shotgun and shot it at the code base I inherited.

    Couple that with being surrounded by developers, who get giddy and scream like little girls watching whatever boy band is popular today, when someone mentions the name Fowler or Manifesto.

    Again…sorry man – I was totally out of line. It was one of those days.

  5. Dave Laribee says:


    As far as cohesion goes I think our approach exhibits good functional cohesion. The presenter contains as much presentation logic as possible. It also owns the model relationship. The view is simply there to display and take input / user gestures. No big news or innovation; that’s what the pattern does!

    Now let’s get into the testability issue. I think you’re going a little far afield from Rik’s presentation in bringing up code coverage.

    If you read that very same thread you’ll see my stance on the issue: namely code coverage is kind of a bogus measure (at best) and potentially damaging local optima (at worst). I’m preparing a post on the subject.

    So the kinds of tests we do in the presentation layer (against presenters, aka – developer testing/BDD) is aimed at capturing presentation logic like: am I validating at a certain point; am I preventing users from closing a view when there’s dirty data; am I opening and closing windows at appropriate time; am I calling a retrieving data when a user clicks a button; am I displaying error messages at the right time; etc.

    In sum – I agree wholeheartedly about code coverage. That said, I think paying attention to coupling and cohesion by bringing in a pattern like MVP will get you more than testability (which is, indeed, important in a lot of cases).

  6. Paul Cowan says:

    >> I’m not sure how cohesion factors into the mix. Would you elaborate?

    I mean by the fact that the presenter has deep knowledge or need to know kowledge about the view.

    Even if this is abstracted by a callback layer.

    I think that again the callback mechanism has been crated for testability.

    Testability is great but it should not influence architecture to this degree.

    The presenter should not be hung up on UI concerns.

    It should just provide and process data .

    I think people have got caught up on the whole code coverage thing.

    A recent thread on the ALT.NET group was from one guy complaining about his devs having hacks to get round 100% code coverage.

    This is a sad statement.

    Do we really get such a return from designing our systems to be totally covered by unit tests?

    Unit tests to me are specification.

    I do get better feed back from integration tests.

    I get the best feedback from a user actually using the system.

    The sooner they can do that the better.

    If I am going to try and second guess every bug that might appear by trying to cover every code path then I am writing code that is of little worth.

    Why stop there, why not have a test that throws every exception in the framework.

  7. Dave Laribee says:


    > The bottom line being I write less code and not more.

    That’s fine when you can get away with it. We try to not write more than we have to as well.

    > As the guy said, there are 6 objects involved in a typical MVP piece.

    Most of which are interfaces. Interfaces provide a nice means of declaring boundaries. For example we use a IViewCallback specific to each triad to formulate the contract between a view and a presenter.

    > That just adds to maintenance and coupling.

    It actually eases maintenance by providing a convention for collaborations. It also reduces coupling by providing a separated interface, i.e. the presenter doesn’t know about the view implementation and the view implementation doesn’t know about the presenter (just the callbacks).

    > The architecture to me would seem to heavily influinced in the need to be testable than true cohesion.

    Testability is surely a concern. I’m not sure how cohesion factors into the mix. Would you elaborate?

  8. Dave Laribee says:


    Well, not quite sure what we’ve done to court your ire. Though I suppose it’s good to be sure the caps lock key works from time to time.

    We practice evolutionary design. We also do a lot of white boarding and some spikes when we encounter a new area. I’m not quite sure how selecting a few common patterns that fit into an architecture counts as the kind of cargo culting you’re quick to accuse us of.

    I’m not exactly sure what point you’re making here, actually. When developing a product I’d say it’s necessary to accept the fact that change happens and a great deal of learning is going to happen. We pursue tests as a means of being able to roll with that change (and it’s associated design changes) in a way that makes sure we don’t introduce regression. Defects due to regression are a big source of waste in software, as is, I grant you rework.

    Again, I’m not sure how this presentation has your blood boiling.

  9. Dave Laribee says:


    You can download the videos at viddler:


    Note the download link under the video. You have your choice of flash or the original format .m4v.

  10. Brian Johnston says:

    MVP was created to solve hardware problems while developing SmallTalk. It has been overplayed in the real world.

    Microsoft first sold ASP.NET (if anyone can remember to 2002) as the perfect MVP implementation because of the code behind model. The HTML was your view, the .NET framework was your controller (it handled the events, page redirects, etc) and the code behind was your model (or pointed to your model…i.e. the BLL).

    Now a short 6-years later Microsoft says ASP.NET is not MVC and not ASP.MVC is the hot topic for MVP. History repeats itself.

    I wish that people would stop worrying about ‘what pattern should I use?’, ‘what Agile manifesto author should I idolize?’, ‘I need to spend 90% of my time make the 10% of my GUI testable’…and worry about writing good software by FIRST AND FOREMOST GETTING GOOD REQUIREMENTS. OVER THE PAST 30 YEARS THE AMOUNT OF BUGS ATTRIBUTED TO REQUIREMENTS HAS BEEN 50% HIGHER THAN ANYTHING ELSE AS A SOURCE OF BUGS (IBM web site has a WONDERFUL article on this if anyone cares to Google for it.

    SECOND – sit down as a TEAM and discuss how to implement the REQUIREMENTS using several CANDATE ARCHITECTURES. This means DO NOT PULL OUT A TOOL WRITE AN ERD AND WRITE OBJECTS THAT MAP TO IT. This means DO NOT PULL OUT A CODE GENERATOR TO START STUBBING OUT CLASSES. This means looking at your USE CASES and writing out some data flow, activity diagrams, whatever, and getting the design write on paper. That way should you choose to use PHP, PYTHON, RUBY, JAVA, .NET, WHATEVER, the design WILL WORK.

    NOW, all you cowboys out there can start stubbing out some candiate objects and writing some tests for that.


    The Inmates are Running the Asylum
    The Pragmatic Programmer
    Pragmatic Unit Testing
    Martin Fowlers – code smell ‘SPECULATIVE GENERALITIES’ – can’t believe how many of you worship him yet haven’t read about that code smell!

    Using a Pattern does not a good program make – in fact more often than not I’ve seen it make a program overly complex and have a sky high maintenance around it. And like any scam artist, those who will respond to this will say it’s the person who implemented it’s fault, not the patterns – oh no it can never be the pattern.

    Well yes it can…they’re called anti-patterns, and this occurs when people try to fit square pegs in round holes and 90% of time when someone is searching through the books and the internet for a pattern to use as if they’re recipes, then the project is going to be bloated and become a maintenance nightmare in my experience…and I have spent the last several years cleaning up other peoples work, so I know a little bit about it.

    If you GATHER GOOD REQUIREMENTS, DESIGN BEFORE YOU EVEN THINK ABOUT A TECHNOLOGY OR DATABASE, WORK WITHOUT A DESIGN PATTERN BOOK/WEBSITE you will grow in YOUR knowledge, and YOUR experience and find that your code will fall into patterns all on its own when ITS REQUIRED.

  11. Paul Cowan says:

    Thanks for the answer and after re-reading my post, it could have been worded more constructively.

    I use TDD myself along with CI and I am sold on the idea.

    I also use ASP,NET MVC, NHIbernate, Castle IOC, Validation, JQuery and Rhino.

    Maninly to give me better productivity and maintainability.

    The bottom line being I write less code and not more.

    As the guy said, there are 6 objects involved in a typical MVP piece.

    That just adds to maintenance and coupling.

    The architecture to me would seem to heavily influinced in the need to be testable than true cohesion.

    I take the opinion of not testing my Views in MVC. The extra effort required does not seem worth the need to test what really is not testable.

    In the same way as now I am woring on a windows service, I am not even attempting to test that code.

    All the code that has the main functionality is in a different library.

    My problem with MVP that the presenter gets caught up in presentation detail which in my opinion it should not.

  12. Dorde Torbica says:

    Can you provide video for download?


  13. Dave Laribee says:


    Maintainability is always an investment. Time-to-market and maintainability are in conflict. We’ve invested in maintainability because we’re in a position to and that was a conscious decision.

    We don’t use DataSets, no. This was a presentation given to a very VB-oriented crowd used to that technology. Some attempt was made, by Rik, to cater to the experience of the people in the room.

    MVP – for me – is standard working practice for any application of more than a few screens/views. Our presenter has evolved over a few projects and is a little scary to newcomers (maybe) but we’re pretty used to it and it doesn’t seem to be a drag.

    Our initial quality (before test) is extremely high. We don’t waste much in bug drag.

    I’d encourage you to think of time-to-market beyond just version 1.0; you’ll have new releases, major and minor. It’s very few companies that can avoid high initial quality. This is especially the case for a start-up trying to capture a piece of an already-crowded market. Not everyone is Twitter. To enhance time-to-market, sure, we can sacrifice on quality, but perhaps it’s better to focus on product ownership and prioritization to hit the right initial notes and trim time. We have a little wiggle room in this area.

    Also, you’ll find, there’s a learning curve to this stuff when deploying to a team. You’ll also find that people get used to it and it gets quicker and quicker.

    So that’s my case. It works for us, we’re happy with this approach, it was an investment, but I’d push us in this direction again, no doubt.

  14. Paul Cowan says:

    It does seem a bit over the top in terms of complexity.

    I mean I originally was never sold on MVP because of the need to create 1+ interface for every page or form.

    But this is another level.

    You have to ask yourself if all this extra coding is worth the testability of the form?

    Are you really getting the payback from all this extra complexity?

    Can you say you have upped productivity?

    Is the number of defects caught worth this?

    Do you really use DataSets in a real world application with all this layering?

    It is obviously very well thought out but it really seems like the time to market is much increased and I know I would have to justify that to somebody.

    Sorry to sound so critical but I am really looking to be proved wrong.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>