Presentation Patterns on Virtual ALT.Net

Posted by Jeremy Miller on August 12, 2009

Just a quick reminder.  I will be speaking on the North American Virtual ALT.NET again this Wednesday night on Presentation Patterns.  This time around I’m doing a *very* informal talk around topics related to Separated Presentation patterns:

  1. What’s the problem?
  2. Let’s enumerate the responsibilities in a view
  3. How do the various Separated Presentation patterns assign these responsibilities, and what’s the fundamental differences?  Passive View vs. Supervising Controller vs. Presentation Model with a quick comparison to the Model 2 style MVC in the web world
  4. Flow Synchronization vs. Observer Synchronization (I’m thinking more and more that this is a very big design issue that isn’t getting talked about very much)
  5. Patterns of View and Presenter/Presentation Model communication
  6. What’s the Model?  Dumb codegen’d objects, ViewModel’s wrapping a rich Domain Model, mobile objects, bind directly to a UI specific Domain Model, or *gasp,* using DataSet’s

Just so we’re clear, this is in support of the Presentation Patterns book that I’m authoring and I’m doing this mostly as a research/feedback activity on my part.  I’d really appreciate any and all questions and feedback.

And as a bonus, if you bait me a little bit I’ll happily rant away on:

  • Why I think the “Zero Code Behind” movement is silly, short sighted, and/or potentially harmless
  • Whether or not the “ViewModel should not know about the View at all!” standpoint adds the slightest value to development (hint: no)
  • How INotifyPropertyChanged, IDataErrorInfo, ISillyInterfaceToSupportRADProgramming crap makes UI development in .Net totally foul up in the Essence v. Ceremony ratio — and what to start doing about it
  • Why I seriously think data binding is overrated and somewhat problematic
  • Why I think the WPF community’s approach to MVVM needs to be questioned
  • It’s a mistake to dogmatically apply Presentation Model when other patterns may be more suitable in certain scenarios (see point 4 above)
  • Questioning the importance of “Blendability” on a typical LOB app

and finally, I may muse on whether XAML is the worst thing MS has rammed down our throats since WebForms…

The previous VAN session on the “Screen Activation Lifecycle” was recorded and available here.  Double click the row to get the recording.

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 Presentation Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://waf.codeplex.com jbe

    Hi Jeremy,

    I like to comment some of your “bonus” statements:

    1) I agree, the “Zero Code Behind” movement is absolutely silly because there are enough situations where this doesn’t work or at least would take a huge effort to make everything “bindable”.

    2) It’s true; the ViewModel needs some way to communicate with the View. This might be done by introducing an interface (e.g. IView).

    3) I believe the INotifyPropertyChanged interface is important for the Model part of the M-V-VM pattern. This is just a generic way to implement the Observable pattern so I don’t see a reason why not to implement it.

    4) Other interfaces like the IDataErrorInfo are too UI specific and shouldn’t pollute the model.

    5) I like to mix the MVVM with the classic MVC pattern to introduce a Controller. Someone has to control the UI process (workflow).

    6) I have never seen another desktop UI technology (e.g. WinForms, Swing, SWT) that is so much fun to program. However, it takes quite some time to understand all the WPF concepts.

    More about my ideas: http://waf.codeplex.com

    Greetings
    jbe

  • http://rauhski.blogspot.com Ryan Rauh

    Jeremy in your VAN talk last week you spoke heavily on the screen conductor, screen activator, screen collection, ect.

    There was a point where you ask if anyone was using PRISM. How many of these patterns/concepts are already present in PRISM V2?

    Perhaps you aren’t familiar with PRISM, but they have the concept of Regions. The region has a collection of views which you can active/deactive and add/delete views from. Is that collection similar to the screen collection with the screen conductor kinda wedged in there with it?

    What I’ve had to do with complicated views is register all the dependencies in the module init and then delegate all the screen bootstrapping to something like a module controller. At least that’s how it was done in the stock trader sample.

    Aside from your distaste for the EventAggregator have you had a chance to look over PRISM. If so, what would you say is good, bad, or lacking in PRISM?

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Christopher,

    I *do* want the view to be as passive as possible, but I don’t see how you could do the binding in another class without totally blowing encapsulation. I still prefer to do the wiring in the code behind, but I was using an FI with Expressions to do all the data binding, events, and minor behavior wiring in one tight little place. I like the analogy to “unobstrusive JavaScript.” I’ll use XAML strictly for layout, then apply behavior to the elements in a well defined, tight area somewhere else rather than inline.

    Oh, and I think the tooling is actually better for the code centric approach. Hands on the keyboard + Intellisense beats lots of mousing around in the Xaml or Blend.

    “Is the problem with data bindings in the XAML that there are error prone and unverifiable in tests? If so, what are your thoughts on the testability framework in Caliburn?”

    I think what you’ve done in Caliburn around the testing amounts to making the best of a bad situation. I’d say that your tooling is a great idea if you’re going to use the Xaml binding. Correct me if I’m wrong, but your testability stuff in Caliburn is really just a smoke test, right? It’s not actually checking behavior, just that the syntax is correct?

    However, I really don’t like the Xaml syntax and it scatters important information all over the document tree. I think it’s much easier to scan the binding/event wiring if it’s all in one place. The other thing I really don’t like about Xaml wiring is the decrease in code “navigability.” That might be tooling, but by making code centric wiring, I can quickly follow the conversation between presenter/viewmodel and view by using R# keyboard shortcuts. I feel that that’s lost by using strings in Xaml.

  • http://devlicio.us/blogs/christopher_bennage/ Christopher Bennage

    So does that mean that you prefer the view to be as passive as is (reasonably) possible?

    If so, I suspect that you would delegate the responsibility of binding view to presenter to a separate class.

    Is the problem with data bindings in the XAML that there are error prone and unverifiable in tests? If so, what are your thoughts on the testability framework in Caliburn?

    And yes, by ‘composing’ I do mean layout.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Christopher,

    “I suspect your dislike of it [XAML] though has more to do with maintenance than initial composition.”

    It’s both. By “composing” do you mean the layout only? That I do (mostly) like XAML for (but from time to time I do it with code for small things). It’s any specification of behavior or even data binding wiring and/or command/event wiring in XAML that gets my particular ire.

  • http://devlicio.us/blogs/christopher_bennage/ Christopher Bennage

    I think that I am more interested in the rants that anything else. Mostly because I agree with them and I want to see if our reasons align.
    The place where we diverge just a bit is over the XAML. I strongly dislike XML, but I think XAML is still easier than composing the UI in code. I suspect your dislike of it though has more to do with maintenance than initial composition.
    In the end, I want to hear what is your alternative to XAML. Perhaps an NHaml for XAML? (That’s fun to say).

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Brad,

    My book is technology agnostic, and the patterns apply just as well to WinForms as WPF (or Swing or Cocoa or even DHTML effects). WPF is problematic to me because it has lots of idiomatic weirdness compared to the others.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @Mat,

    I’m going for a patterns/concepts book. It’s not really a .Net book. At this point, I’m not talking much about patterns for web apps (but that might change).

    I’ll even have some *gasp* Java samples.

  • http://moleseyhill.com mat roberts

    Hi Jeremy,
    In your book are you going to divide up on technology lines (e.g. sections on web forms, mvc, wpf etc.) or are you writing patterns which span the technologies?
    Cheers
    Mat

  • Brad Mead

    I was recently shown the Michael L Perry code magazine article on using his open source library to render INotifyPropertyChanged obsolete. Personally, WPF is new to me so I didn’t really want to ditch familiarity for a quick-fix helper assembly just to get data to the screen elements. Perhaps I’m being too naively predisposed?

    I like low ceremony (or a high essence to ceremony ratio), but I have an almost aversion to non-incorporated external dependencies that aren’t sufficeintly justified. I would very much appreciate your thoughts this.

    Also, I think I started a question the wrong way last week. So if you could please touch on it for clarification. Specifically, will any of your presentation patterns/explorations be applicable/relevant to WinForms? It would seem at first glance they could but I’m too ignorant of the UI framework coupling that might prohibit cross-framework usage (i.e. WinForm’s direct-object UI elements vs. interpreted markup XAML).

    Thanks,
    I’ll take my questions off the air.

    Brad