WCSF Application Architecture 1: Introduction

[Edit] By popular demand (well, one request!) I've added links to all the articles in this series here;

WCSF Application Architecture 1: Introduction (this post)
WCSF Application Architecture 2: Application Controller
WCSF Application Architecture 3: Model View Presenter
WCSF Application Architecture 4: Environment Abstraction
WCSF Application Architecture 5: Defining Modules
WCSF Application Architecture 6: Structuring Modules
WCSF Application Architecture 7: Remote Logic with WCF Services

[/Edit]

One of the questions I get a lot from customers is “how do I write a real world application using the Web Client Software Factory (WCSF)?” The problem is that I think everyone writes applications slightly differently, but also significantly there is no single correct way. What is important is to get two things right;

Select an approach

I honestly believe that one of the best ways to improve the quality, maintainability, and document-ability (no really, I’m sure that’s a word!!) of your system is to pick a single approach and stick to it throughout the application. What is even better is to consistently use the same (or a gradually evolving and improving) approach throughout all your applications.

The developer learning curve is massively flattened if you do this – everyone knows how to add operation X to page Y, because they all follow pattern Z. With this consistency in place you should find your team feels really comfortable, reassured, and secure in what they’re doing. I think this is really important. It then gives people the confidence to innovate in the important areas (that small percentage of an application that needs to be “special” in some way) and to understand how they might evolve the approach for next time, into something even better.

Of course, documenting your software is made much easier by having a consistent approach too – it tends to lead to the evolution of natural terminology (often driven from or derived from patterns you’re using) that the team use when communicating, whether that be on paper or verbally. I can’t count the number of times I’ve been in team meetings when someone has said something like “have you re-gened the DTO and DTM, because my Presenter needs updating to reflect the changes to the user Catalogue”. Everyone knows which project and folder the DTO, DTM, Presenter, and Catalogue classes live, and everyone knows what they do. Therefore;

stress -= 10;

communication ++;

 

Select an appropriate approach

OK, so I admit that this is cheating. It’s like saying “to have a happier life, do everything right”. Don’t you hate it when you get to the end of a “how to do X” article and it basically tells you to go and work it out yourself?

Well I won’t be quite such a pain – I can help with this. I think there are a standard set of variances that I have seen in how people use the Web Client Software Factory in particular, and therefore my intention is to describe how these variances might help or hinder you, and which I tend to favour in different situations.

The two main drivers behind variances in implementation in my mind are the different interpretations and uses of Modularity and Patterns.

The WCSF brings a strong modular approach to solutions, encouraging you to split your application into Business Modules and Foundation Modules. You can find more information on these concepts here. I will explain some differences in how you might choose to implement these modules, and how you might split your application up.

The Model-View-Presenter and Application Controller patterns are also used extensively in the WCSF. Some useful information on this can be found here, here, and in this great article on UI patterns in general. However, the way that people use these two patterns in the real world actually differs in quite subtle ways, which can have an impact on how much effort is required to write and maintain your application, and I find personally on my perception of how worthwhile using the patterns is. For example, having to write an extra 6 classes and 12 methods to format a string is bad in my mind, but separating the logic to format the string from that to display it is good. There is always a balance there somewhere!

 

Assumed Application Structure

Throughout all my posts I am going to assume that the most common case of application architecture is known to you – and that this is our starting point. The architecture I am referring to is the common interpretation of that described in Application Architecture for .NET. That is, it looks something like this;

Layering

Not rocket science, but a common starting point for us all.

 

Watch this space

So, stay tuned. I’ll post some follow-up articles to this that hopefully will shed some light on what the differences are. Feel free to chip in – if you love or hate one of my suggestions, or think I’ve floated a good or bad idea, shout up in the comments section and help me get a real feel for how people are doing this around the world.