First things first, how did I catch the mistake? These were my tests, including the one that caught the issue:

I was only receiving the start and end events and no others. To fix my mistakes, I ended up with two interfaces from my original interface so that I could appropriately apply my decorators:

However, this is now getting ridiculous. Nevertheless, deadlines were coming up, and I persevered. You’ll have noticed also that my api changed slightly. Instead of passing in the path and calling a static method on SpreadsheetDocument, I’m now passing in the SpreadsheetDocument. Much nicer for testing, especially since .Rows() is already my own extension method. I also have a public property for the item loader on the detail loader. I’m not thoroughly impressed, but it works.

Once I updated my tests:

and my implementations (note that my FakeDetailLoader became the implementation of FakeDetailItemLoader and DetailLoader is no longer an ugly abstract base class):

Maybe you can now see why it’s taken me awhile to post this. It wasn’t difficult, but it sure was tedious, and a little ugly. I’m not sure it was worthy it for this simple demo, and I wasn’t sure on my project. I was later proved right, however, when we kept receiving increasingly complex requirements. Decorator to the rescue!

In the meantime, I hope to start emphasizing the usefulness of developing with patterns. This post was inspired by Sean Chambers recent 31 Days of Refactoring (e-book) and my recent flub when trying to describe the Decorator pattern (ducks, really?).

Setting the Stage

On a recent project using WPF and Prism, we’ve built business layer objects to import and export text and Excel files in batches. These batch processes included importing data, transforming the data into something useful, and persisting the transformed data into our database. We needed to communicate progress back to the UI for each of these tasks to keep the user aware of progress, as these tasks can take quite a long time, especially with multiple files. The initial design was raw and messy with lots of code duplication to explicitly create a BackgroundWorker directly within each ViewModel to start the import/export process and listen for events fired directly from our business objects (which essentially follow the Transaction Script pattern, more or less).

Another co-worker, when he was tasked with building another importer, created a subclass of our base ViewModel class and added all the BackgroundWorker plumbing, then did the same for our base business object class. He also created a ProgressItem : INotifyPropertyChanged type with methods to Start(int items), StartAsIndeterminate, IncrementProgress, EndWithSuccess, and EndWithFailure. He also added a collection wrapper for ProgressItems to allow ease of registering and auto-subscribing (through the AutoNotify method) the owning business object to the PropertyChanged events of the ProgressItems. With this setup, the UI ViewModel could listen to the PropertyChanged events of the business object’s ProgressItems instead of having the business object fire its own events. As you can imagine, this made implementing a batch import / export process immensely easier.

I eventually went back and refactored all of our existing business objects and ViewModels to follow this approach. Not only are both the business objects and ViewModels easier to debug, they are also easier to test since we are no longer firing events, just updating the state of a given ProgressItem. Well, sort of….

My Turn

I was recently tasked with creating a new batch import process to pull data from Excel. I started by following the pattern JB set up and had the initial steps of my batch import object ready to go. (I also confess to not having written any tests yet because, to date, we hadn’t figured out how to mock out the SpreadsheetDocument, Rows, etc. from the Open XML SDK we’re using to assist in our import / export tasks. I’ve now solved that problem and retro-fitted in unit tests. I’ll post that solution later.)

Identifying the Problem

After taking a step back to look at what I had done, I quickly realized that I was violating SRP with the inclusion of the ProgressItems in each step. Some might think that’s not such a big deal; after all, calling start, increment, and end on a single object is only three lines, which doesn’t seem like a lot. However, multiply those three lines by the number of import/export objects and factor in the number of times we forget just one of the them, and you begin to appreciate removing the extraneous bits.

I’m quite certain I noticed this primarily because of my study of functional programming rather than any object-oriented pattern literature I’ve come across. Nevertheless, I considered only OO patterns for the solution simply because the alternative was likely a monad, and that just scares the pants off of most people. (And I like my co-workers.)

The Contenders

I needed something that could pull the ProgressItem out of my actual import procedure and allow me to focus that logic purely on the import. The two patterns that came to mind were the Decorator and the Visitor.

The Decorator is generally considered (well, at least by the people I know) the simpler of the two. It wraps and extends an object without changing the underlying object and still providing the same interface. Examples include “decorating” coffee with sugar, cream, etc. and returning an adjusted price for the additional “decorations.”

The Visitor, on the other hand, is passed into an object’s void Accept(Visitor visitor) method and provides some resulting side-effect through the visitor itself. Examples include pretty printing, which print a tree-structure with the appropriate indentation, or adding the appropriate tax to an order. Another example for those using the System.Expression namespace would be using the ExpressionVisitor to allow the use of POCO objects with Entity Framework v1, as JB demonstrated here. (For those familiar with monads, you’ll likely see some resemblance.)

In this case, I had the following interface:

For reference, the initial state of a Loader looked something like this, making adjustments to the method signatures for the addition of the ProgressItem, which initially was passed to each method:

Enter the Decorator

Instead of muddying my interface with a void Accept(Visitor vistor) method, I chose to just decorate it. My resulting decorated class looked as follows:

The resulting base DetailLoader looked like so:

This made the loader much easier to reason about and test thoroughly, as the ProgressItem is completely removed. I no longer have to remember to add the calls to it or even bother with anything other than loading data. Again, I know some will probably call this an over-engineered example, but as a developer who has had to debug these things when they were initially one method directly on the business object not firing a particular event, the additional abstractions make this a breeze to create, debug, and test. To each his own.

Testing

As I mentioned, I figured out a way to test this against the Open XML SDK, but since this is already quite a long post, I’ll postpone that for later. I hope you find this a helpful explanation of how and when to refactor using the Decorator pattern. Please let me know if you have any feedback on the matter.

Dogs and Cats Living Together

You’ve probably read Joel’s post on The Duct Tape Programmer and several responses. I did not like Joel’s post at first, as I thought it far too general and easily taken in the context of “always do it this way.” For the record, I have no problems with the duct tape approach when trying something out, but I’ve been burned when having to work on someone else’s let-me-try-this project that then became a core, production system. That’s a formula for PAIN. That said, I think you can make a case for using a duct tape approach for some, small parts of your application.

This past week I put together a presentation on DDD for my office. I included some slides describing DDDD and CQS as Greg Young has discussed time and again. While I put together those slides and thinking about Bounded Contexts, I had a sudden realization that even within a single Bounded Context or Module, you could mix duct tape with quality when using CQS.

If you look at the diagram above, you can easily see where this is possible. If you split your module into read and write contexts, you can focus your greatest efforts for quality on the write side, where your domain lives, and leave the ever-changing read side to duct tape, RAD, etc. for displaying in the UI or reporting. The idea here is that you will often find that what you need to persist doesn’t change very much, but what you are asked to display changes nearly constantly. That’s at least my experience.

Another benefit to this approach is on the sales pipeline. Creating applications consists of these two parts: reading and writing. You may find that clients who have their own internal developers may not want to hire a consultant or contracting firm to build an entire app at their normal rates, but if you can provide them the write side and architecture guidance for the rest of the app, you may be able to sell more projects and keep your people happy working on quality code and quality projects. Of course, that’s just theory at this point.

So is this a case of “mass hysteria”? I don’t know. I like the idea, if not so much for the inclusion of duct tape as the possibility of limiting changes to the core domain models in an application architecture. I’m curious to know what others think or have done.

Also, it was nice to be finally finished with my two presentations. Both were fun but I will admit to liking my Evolve Your Code material a bit more than the WPF Input Validation. They were both a lot of work. Be sure to thank presenters. I knew work went into the presentations but I didn’t appreciate how much until I tried to do two. I learned a lesson with that decision. Never do 2 new presentations. It’s way too much work and both suffer from neglect. I will write a post on all my presentation lessons later.

Without the 2 presentations looming over me and my new job, I should be able to get back to blogging more. I love sharing what I know, even if its just to myself months from now when I forget everything.

For the slides I am trying out slideshare and am also using Git Hub for the slides and solutions.

Evolve Your Code:

http://www.slideshare.net/RookieOne/evolve-your-code

http://github.com/RookieOne/Evolve-Your-Code

WPF Input Validation:

http://www.slideshare.net/RookieOne/wpf-validation

http://github.com/RookieOne/WPF-Input-Validation

HTML was designed as a document format with hypermedia connections to other, related documents. Today, however, we abuse HTML and treat it as an application platform. It somehow performs remarkably well in most cases. I suppose that’s a testament to the agility of declarative markup. Nevertheless, I think we could all agree that HTML at least started life as a document format. If this is the case, I argue that HTML is not a view format; rather it is a serialization format for a model.

I’m sure many reading this are probably calling me a fool or worse. Well, don’t take my word for it. Let’s look at what some of the leading web developer/designers are saying:

In markup, semantics is concerned with the meaning of an element and how that element describes the content it contains.
-Molly E. Holzschlag (http://www.informit.com/articles/article.asp?p=369225&rl=1)

Although it might be tempting to use the visual layout as the basis for the structure of your markup, this could lead to you overusing elements, particularly <div> elements. This will also result in establishing your content order primarily to accomplish the visual layout rather than it making sense when no style sheets are available. To avoid presentational markup and ordering problems, begin by first looking at the content and then working out from the meaning(emphasis mine).
-Andy Clarke (Transcending CSS)

The notion that HTML is a display language has been proven long ago to be a Bad Thing. CSS taught us to separate our presentation from our content, and the doors that opened when we did it were invaluable. Today, however, we’re still delivering web applications as HTML documents with a bit of scripting layered on top. This works, but is strangled by all of HTML’s limitations. Fundamentally, HTML is not an application delivery format, it is a content description language, despite the valiant efforts of the HTML5 Working Group.
- Meitar Moscovitz (SVG Is The Future Of Application Development)

No, I can’t quote them directly, but I believe my argument has the same spirit. We should look at HTML as a PresentationModel, or ViewModel if you prefer, in the client (i.e. the browser). Therefore, HTML be treated as a serialization of your object model into a document format.

What then is the view? What’s the controller? These are excellent questions. Let’s think about how MVC works. The controller is responsible for receiving requests and relaying responses. The view is supposed to display the representation of the model. For the web, the controller easily aligns with the HTTP protocol and the view to the styles, transforms, and behaviors applied to the model (our HTML document). (I’ve used styles and transforms here separately to emphasize the potential use of XSLT stylesheets in addition to CSS.) Sure, using a document serialization, you could just display the model directly, and the confusion of HTML is here emphasized. It’s a model built out like a visual representation.

Are there some exceptions to this? Sure. If you want to treat HTML as a purely view format, then you can eliminate everything from your HTML except for JavaScript bindable areas and use JSON objects as your PresentationModels. Pass some of those around instead of HTML, and you’re really treating HTML like a true view. However, we don’t generally do that. We usually serialize the model into the HTML and apply our view aspects afterward via CSS and JavaScript.

If we really want to get serious about making an excellent MVC framework, we have to recognize and use our building blocks appropriately. HTML is a model serialization format. Treat it as such.

This morning, however, I had the thought of creating a fluent interface for one of the most simple of concepts used in .NET: collections. What’s wrong with collections you ask? Nothing really. But what if instead of reading

collection.Add(item)

you could read

Add.the(item).to(collection)

? Which is more readable? In the end, that’s similar to what I’m doing with the System.ServiceModel.Syndication bit, except that you don’t generally just add one or a few things to the collection in the syndication example. We could create something similar to add and remove events, all using a single static Add/Remove class with various, overloaded methods for the common identification operations.

Is this overkill? As JB mentioned to me over IM, it’s relative. For some, I’m sure you will think I’m nuts. Others may think I am on to something. I don’t think I would go and do it for no reason at all, but if I ended up with some crazy list creation or end-user-wants-to-read-my-code scenarios, I might consider something like that. What do you think?

I thoroughly enjoyed the post and greatly appreciate practical discussions on WPF/SL application patterns. I am a bit of a WPF nut having lived and breathed xaml for over 2 years. I’ve been a part of 2 successful WPF projects (both in production). In both scenarios I acted as the defacto WPF guru.

This last project was a typical line of business application and we used the ViewModel pattern with Prism. I bring all this up to share my background with WPF and ViewModels.

Concerning the content of the post, I agree with Glenn on the majority of the content. The Commands and Parameters especially rings true. I found that whenever I went with option A [using element binding to a command parameter] I ended up refactoring it to option B [binding the ‘selected’ item to a property on the ViewModel]. Although a neat use of xaml, in practice the binding to the property just allowed more flexibility that indubitable becomes necessary with future changes and demands (not to mention testing opportunities).

With both projects we didn’t have the luxury of a full time designer. In both scenarios I argued there was plenty of work for a designer, but alas the resources just weren’t there. We were able to use a designer for a decent chunk of hours, but more could have been done. The applications were definitely better off for having every hour we could get from any designer resource. I believe the last project persuaded many that indeed there was enough work for a full time designer, so maybe I can hope for a designer with a future application.

I say this because I can not speak towards what its like having a designer in Blend all the time working on Views. When we used a designer resource, they would work in Blend and then a go-between developer / designer would take the xaml and integrate it with our ResourceDictionaries.

What I would like to address is the ‘no code behind’ philosophy compared to the code behind practicality.

Two years ago when I was floundering for WPF information and blogs, I ran across a blog post (I want to say it was Josh Smith) where the writer stated something like : “if something is easier to do in the code behind then its okay to do it in the code behind.”

He was arguing that a crap load of xaml vs a couple lines of code behind isn’t an argument at all. The code behind is the best choice. Naturally clearer intentions and code maintainability takes precedence over having a dogmatic “everything in xaml” approach.

With this last LoB Prism application, we had some choices to make when we were deciding on how the client should be made up.

Do we use UserControls as Views or (as Ryan Riley brought up) do we use Data Templates as views. I felt at the time the team wasn’t ready for that leap to Data Templates as views. I considered the code behind of a User Control as a placebo safety net for a team struggling with the WPF learning curve. What I did do was firmly encouraged a no code behind policy. A “no code behind” challenge if you will.

If I were to go back to the beginning and make that View decision again, I would go with the Data Templates as views. The team did very well without using the code behind. A Data Template view would have brought more benefits than the cost of having no code behind. Often we found ourselves thinking.. if this view was a data template and not a user control, then we could more easier do X.

I have championed the “no code behind” stance internal to Catapult and to other developers. Yes you can legitimately use the code behind to accomplish certain tasks. More often than not though (in my experience), the use of the code behind has more to do with the prejudices carried over from WinForms development. Having a strict no code behind stance forces developers to learn and change the way they think about coding functionality into the UI.

Glenn came up with a scenario (albiet a overly simplified one) of where he felt a code behind had some value. The scenario described is:

‘”The user clicks a Save button on the Edit Order screen which requires some UI cue to the user such as an hourglass while the order is saving, and another cue once the Order has saved.”

He argues that the code in the xaml is less testable. He even suggests the solution I made. He also recognizes others my disagree. Count me in the disagreement camp.

I created a simple project that uses Attached Dependency properties to accomplish this simple scenario. This isn’t a “throw down the gauntlet” sort of thing and I didn’t really write it for Glenn. A coworker emailed Glenn’s blog and I responded in an email describing my solution. He then asked to see it in action. So I coded it up.

He also asked me to post a comment on Glenn’s post, but I don’t really see the point especially since I agree with the information Glenn is sharing and his opinions are built on experience & expertise. I really had no disagreement and the solution Glenn already knows of. /shrug

Anyway.. you can find the solution here : http://github.com/RookieOne/AttachedAnimation/tree/master

Before moving on, let me just say that by no means am I advocating WebForms or other, similar frameworks. Such things are atrocities that should never have been committed upon this earth. (Okay, I exaggerate a bit, but hopefully you get my point that while I’m about to rag on MVC, some of these other things are worse.)

As I wrote, this thing became far too long for a single post, so I’m breaking it up into sections. I also need to find and tie in the discussion I had with JB about this very thing. I like how that discussion went, although it was based upon other discussions similar to those in the following posts:

1. A History of Violence against HTML
2. New Names for Old Things
3. Serve me up some of that good ole Appl(ication)e Pie
4. The Web is a Service Bus
5. The Gauntlet

So stay tuned. There’s more to come.

Perhaps it depends on the implementation, but if you follow SOLID principles, I think you will at least end up with a validator type that performs the validation, either as a strategy on the model or a separate service.

We started with self-validating anemic domain models on my last project. That’s possibly an oversimplification, but it worked well for those models that were truly used in a CRUD-only manner. More complex models quickly became difficult to maintain, and as part of the refactoring, we split out the validation duties into their own class and now provide validation through the service layer for the client. This acts as a sort of anticorruption layer (Evans).

I really like this approach best. You can still call the validation from the client before sending, and your model may continue to focus on it’s real job. What are your thoughts or preferred approaches?

I would like to see a ViewModel base eventually, though, as that would be one less thing to wire up myself, and it hopefully silence all the people complaining about the lack of a model in MVC. (Yes, I am thinking the backend models should be sharable among WPF, Silverlight, and MVC.)

Glenn’s second question related to tv target audience. I am always a fan of simple explocicity, to borrow a word from JB. I think that’s what the experts use. Also, I don’t know many who want to me mediocre some day, so going for the best and letting it trickle down is a great idea.

Just my $.02.