Simon Ince's Blog : Software Factories

Do you need web client development help?

simonince — Tue, 21 Jul 2009 15:01:00 GMT

Then tell us what you need! Blaine has blogged a link to a survey that patterns & practices will use to help them understand what challenges that are affecting you the most... so that they can choose the right areas to focus effort in providing guidance.

If you’ve got a couple of minutes spare head over to the survey...

What tasks or areas are difficult? What consumes the most time? What is it that causes you post-deployment headaches? What parts of the process are tricky? What don't you do because it is hard?

Blueprints Update

simonince — Thu, 18 Jun 2009 22:40:00 GMT

This is late news as I’ve been busy recently, but if you’ve been following Blueprints make sure you read Michael’s post here. They’re evolving into something else, that I’m sure will be even more exciting...

I’ll be staying tuned so no doubt I’ll shout up when I hear more.

Blueprints Example: View-Presenter, Part 2

simonince — Fri, 19 Dec 2008 15:59:00 GMT

This article follows on from part 1, so make sure you know how far we got. Basically we can generate a project according to our required template, so next we want to be able to add a new View-Presenter enabled Web Page to the project.

We’ll do this using some T4 text templates – one for each file we need to create.

Note: Remember this is based on the November 2008 CTP, so it may not work in future versions.

Menus and Commands Primer

To allow us to do this, Blueprints has notions of Menus and Commands that work together to achieve what we want. Both are configured by right-clicking your Blueprint Factory (the “ViewPresenterFactory” project in our case) and selecting Blueprints->Edit Configuration. The Menus and Commands tabs contain configuration for each item.

A command is something that can be executed, that does the work for us. These commands can be built-in, written in C#, or declared as Windows Workflow XOML files. In this post we’ll look at writing a C# one, known as a “C# Command Extension”.

A menu is simply a way to provide an entry point to a command for the user. We specify what the menu item should be displayed as, and when it should be available. When clicked, it can invoke our C# command.

Creating a Command Extension

As with almost all Blueprint Factory tasks, we start by right-clicking our Blueprint Factory project and selecting Blueprints, this time clicking “Add Command Extension…”. Specify a name for your extension library – in my case, I chose “Commands”.

The Blueprints runtime then actually unfolds a Blueprint (the command extension Blueprint) to create a new project for you and set up a post-build copy of the Commands assembly into the ViewPresenterFactory project’s “extensions” directory. This ensures the command is included in the Blueprint package when you come to deploy it.

Next, right-click your solution and select “Project Dependencies”. Ensure that ViewPresenterFactory depends on Commands; this means that Commands will always be built first, so when you do a build the factory output will contain the latest Commands implementation.

The core of a command extension is the “ExtensionClass” class that is generated for you. You could rename this if you like – although I haven’t in this example. This class is instantiated at runtime, and the “execute” method is called with some parameters, including the name of the command to execute. Therefore, in my execute method I have code like this;

switch (command)

{

case "CreateWebPage":

CreateWebPageCommand(context);

break;

default:

break;

}

The meat of the “CreateWebPage” command is handled in another method.

What we want to do, then, is as follows:

1. Prompt for a Web Page name, such as “MyWebPage.aspx”.

2. Generate five files from T4 templates that make up the Web Page and its matching View-Presenter classes.

3. Add all five files to the host project.

These five files are;

· “MyWebPage.aspx”, to hold the HTML markup.

· “MyWebPage.aspx.cs”, to hold the code-behind.

· “MyWebPage.aspx.designer.cs”, to hold the designer-generated code behind (that a developer wouldn’t normally touch).

· “MyWebPagePresenter.cs”, to hold the Presenter class. This is stored in the Presenters folder.

· “IMyWebPageView.cs”, to define the View interface. This is stored in the Views folder.

I’ve created some helper classes to make this easy, so my command code looks pretty neat and tidy at the moment;

// create the T4 arguments

Dictionary<string, T4PropertyData> args =

new Dictionary<string, T4PropertyData>();

args.Add("ViewName",

new T4PropertyData(chosenName, typeof(string)));

args.Add("ModuleNamespace",

new T4PropertyData(env.SelectedProjectNamespace,

typeof(string)));

// build a list of files to transform

List<TransformItem> transforms = new List<TransformItem>()

{

new TransformItem(

"IView.cs.t4",

format("Views\\I{0}View.cs")),

new TransformItem(

"Presenter.cs.t4",

format("Presenters\\{0}Presenter.cs")),

new TransformItem(

"ViewPage.aspx.t4",

format("{0}.aspx")),

new TransformItem(

"ViewPageCodeBehind.aspx.cs.t4",

format("{0}.aspx.cs")),

new TransformItem(

"ViewPageDesigner.aspx.designer.cs.t4",

format("{0}.aspx.designer.cs"))

};

// perform all the T4 transforms

TransformHelper.CreateFilesFromT4(

transforms,

args,

context);

// add all transformed files to the project

// the user clicked on

List<string> files =

transforms.Select(

t => t.TargetFilename).ToList();

env.AddProjectItemsToSelectedProject(files);

We build up the list of parameters to pass to each T4 template – in my case they all need up to two parameters, which are the same for each template, and specify the name of the Web Page and the namespace. Then we build a list of templates to transform and their target filenames. This list is passed to a helper to perform the transforms themselves.

Finally, a quick LINQ statement pulls out the list of target filenames and uses another helper to add each file to the project that was clicked on.

An Example T4 Template

Before we go any further, let’s have a quick look at one of the T4 templates. These are all stored in the “ViewPresenter” folder of the Commands project. They must also be manually copied to the “content” folder of the “ViewPresenterFactory” project in order to be included in the factory package. I suspect this will change in the future, but for now, don’t forget!

<#@ Template Language="C#" #>

<#@ Assembly name="System.dll" #>

<#@ assembly name="Microsoft.SoftwareFactories.BlueprintsAPI.dll" #>

<#@ Import Namespace="System" #>

<#@ property processor="T4PropertyProcessor" name="ViewName" #>

<#@ property processor="T4PropertyProcessor" name="ModuleNamespace" #>

using System;

using System.Collections.Generic;

using System.Text;

namespace <#= this.ModuleNamespace #>.Views

{

public interface I<#= this.ViewName #>View

{

}

This template shows how the definition of the View interface is generated. I’ve declared the language of the template, and imported any required assemblies and namespaces. Note that you must have a reference to Microsoft.SoftwareFactories.BlueprintsAPI.dll as this is the host for the T4 engine in Blueprints.

The other key part of setup is declaring the properties this template depends on. In this case, we have ViewName and ModuleNamespace – they should be familiar from the setup of the T4 arguments in the command code above, in the ExtensionClass class.

Finally, the syntax of templates is very similar to ASP.NET – the use of <#= #> sections allows the injection of code that is executed when the template is processed. If you like the syntax highlighting above, I’d recommend checking out Clarius’ T4Editor Visual Studio plug-in.

Inside the TransformHelper

I’ve included the code with this post because it is simple enough to have a look through, rather than spend many words explaining here. The TransformHelper is based on the sample code generated when you first create a C# Command Extension – I’ve just tweaked it a little to suit my needs further.

The core of the task is in getting a reference to the T4 service and requesting a render;

object t4Obj = BPMServices.BPMGetResource(

new Guid(BPMConstants.T4ResourceGuid));

IT4ResourceAPI myT4 = t4Obj as IT4ResourceAPI;

if (myT4 != null)

return myT4.Render(

context,

templateText,

templateFilename,

args);

This uses some Blueprints infrastructure to get hold of the T4 service, and then executes it – notice the “args” parameter to Render is the Dictionary we created in our Command.

Wiring up a Menu

Last but not least, we need to make it possible to reach this Command. As we’ve said already, the trick is the combination of Commands and Menus.

First we must effectively “register” our new command. Open the Blueprint configuration for the factory, and click on the Commands tab. Click the “Add” button, and we can add our custom command.

We must be careful to ensure the settings on this screen match how we have created our command to be successful, so to summarise;

· “Command” should be the name of the command that you respond to in the switch statement inside ExtensionClass.execute. In my case, this is “CreateWebPage”.

· “Host” should be the full assembly name of your “Commands” project. Note that this is not “Commands.dll” (which is what I expected). The Blueprints Factory actually set mine to “ViewPresenterFactory.Blueprint.ExtensionClass.dll”. Check this by viewing the Project Properties dialog for your command extension project.

· “Class” should be the name (including full namespace) of your extension class. In my case this was easy; “Commands.ExtensionClass”.

The result is a screen that looks like this;

Next, we must make this available to the user by linking it to a Menu.

This is really easy; click on the Menus tab, and hit Add. This time, the following fields should be filled in;

· “Caption” should be whatever you want to appear on the context menu.

· “Command” must match the name of the command in the previous step, which also matches the string you check for in your switch statement in the command extension.

· “Visibility” defines when the menu option should be displayed. For now I’ve set this to “ThisProject”, which will display it as part of the context menu on the project itself (I wanted to do this at folder level but couldn’t get it to work yet). There is more information on Visibility Filters in the Blueprint Factory workflow, under “Adding context menu items and BPM extensions”.

Mine looks like this;

Done! Give the Blueprint a build and you’re ready to test it. Do this by opening a new Visual Studio instance, creating a blank solution, and then unfolding the View Presenter Blueprint into it using the Blueprints Manager from the Tools menu.

How Does It Look?

The end result is that I can right-click on the newly unfolded template project and choose to add a View-Presenter Web Page;

I then get a prompt for the name of the Web Page using a simple dialog I have written;

… and finally, a new page with a matching IView and Presenter are created for me.

I can then immediately start adding code. I’m sure you’ll see this example isn’t perfect – I can’t put pages in subfolders yet, but this is a CTP after all!

Conclusion

That’s all been pretty straightforward, but I hope it has demonstrated how quick and easy it is to get up and running with providing guidance that adds real value. I believe using approaches like this to bring consistency to development provides real tangible benefits.

Also, bear in mind we’ve done one of the trickier Use Cases of generating code – I haven’t covered just creating textual advice in the Blueprints process workflow (although the downloadable source code includes a bit), which is really really easy, yet in itself could be invaluable to many development teams.

Blueprints Example: View-Presenter, Part 1

simonince — Wed, 17 Dec 2008 14:47:00 GMT

I’m sure I’ve warned you before – I’m a big believer in Software Factories… but I’ve been quiet about this for a while now. That’s because I’ve been waiting for the ‘next big thing’… enter stage left: “Blueprints”!

I had the pleasure of attending a talk that Michael Lehman and Jezz Santos gave in Seattle a while back, and more recently I’ve spent a little time recently playing with the CTP available on codeplex, and getting a feel for how it works. I thought others might find another example useful, hence I’ve posted my thoughts here. Basically I wanted a simple example to use to generate a Blueprint, and so I chose adding a web page that adheres to the View-Presenter pattern.

If you’re after background information, you can’t miss the codeplex site, the MSDN landing page, and Michael’s webcasts.

One word of warning: This is based on the Nov 17^th 2008 CTP, so chances are it’ll break in future releases.

Creating a Template Project

The usual behaviour of a Blueprint Factory when invoked is to “unfold” a project template into your solution. By default this is a basic C# project, but we want a Web Application project with some structure in it.

To do this, we can first create a simple “ViewPresenterTemplate” Web Application project in Visual Studio 2008 as you would normally, and add “Views” and “Presenters” folders. Then implement the View-Presenter pattern on the “Default.aspx” page… the result looks a bit like this;

Next, we need to export this as a template that the Blueprints Factory can consume; so in Visual Studio select File->Export. Then export the project as a template (ensuring you don’t “automatically import…” it into Visual Studio again), and locate the new zip file.

So now we have a nice template project, we need to create our Blueprint Factory.

Creating a Blueprint Factory

Once you’ve installed all the Blueprints bits, you can access the functionality from the Blueprints Manager on the Tools menu. First create a nice blank solution, and then pop the Blueprints Manager up and choose to unfold the “Microsoft Blueprints Factory 2.1.1” Blueprint. It will then prompt you for the Project Name of the Blueprint Factory. I chose “ViewPresenterBlueprint”.

Next you can fill in some the basic details of your new Blueprint. Just fill in the Configuration tab for now. Note that the “Description” field is what is displayed to the user when selecting a Blueprint to unfold, so make it fairly explanatory.

The Template field is important for us in this example. By default, it is set to “Auto-generated”, which means when you unfold a Blueprint it will generate a new C# project for you. That’s not what we want, so we’ll come back here in two minutes.

Attaching our Template

After hitting OK you’ll see your new Blueprint Factory project all ready to go, and the guidance window (or “Blueprint Workflow”) will be displayed. Next, we need to find our template ZIP file that Visual Studio created for us. I renamed mine to “Template.zip”.

A Blueprints Factory project has a special folder to hold templates, aptly named “templates”. The easy bit, then… drag your “Template.zip” file into the “templates” folder in your ViewPresenterFactory project. It should look a little like this;

Finally, to ask the Blueprints Factory to unfold our new template instead of the default C# project, we need to edit the configuration.

Right click the ViewPresenterBlueprintFactory and choose Blueprints->Edit Configuration. Replace the “auto-generated” Template option with “User supplied”, and type in the filename of your newly added template;

Hit OK, and give your Blueprint a build.

Testing the Blueprint

At this point, you could unfold your new Blueprint into the same solution, but I prefer to do it in another instance of Visual Studio. This is because Command Extensions (what we’ll see next time) remain in memory, so you need to restart Visual Studio to unload them anyway. But I also find it doesn’t make such a mess of my factory solution’s local directory.

So, spin up a new Visual Studio, open the Blueprints Manager, pick your Blueprint and click Unfold. It will ask you for a solution to add it to, so just select “Other Project Types->Visual Studio Solutions->Blank Solution”, and give it a filename. Then you’ll be prompted for the project name for our Web Application project.

One thing you’ll find when testing is that you create a lot of these solutions (which is probably why some prefer to unfold into the same solution as the factory). Therefore I’d recommend putting them all under “C:\Testing” or something that will remind you they can be deleted.

When you unfold your new Blueprint you will see an exact copy of the ViewPresenterTemplate project we created earlier.

What next?

So far our factory doesn’t do a lot, you’re thinking! It creates a template project, and nothing else. But in the next step we’ll be taking it further... specifically by allowing a user to add a View-Presenter enabled Web Page.

Watch this space for the next post shortly.

Are you using the WCSF?

simonince — Fri, 05 Dec 2008 17:10:00 GMT

Have you been using the Web Client Software Factory? Or have you tried it and not adopted it? Or have you used some of the bundle content but not the whole factory?

Michael Puleio has just started a thread on codeplex requesting feedback on who is using the factory, and talks about it briefly in this post.

Combine that with Blaine’s WCSF Roadmap post and you can see p&p are already thinking about the next version of guidance for ASP.NET applications. Now is the chance to comment on what really matters to you, and what would help you in your day-to-day job.

WCSF Application Architecture 3: Model View Presenter

simonince — Wed, 11 Jun 2008 11:58:00 GMT

This article is part of a series;

· WCSF Application Architecture 1: Introduction

· WCSF Application Architecture 2: Application Controller

Model View Presenter

The MVP pattern is effectively an evolution of Model View Controller, and is mainly geared at improving the structure and testability of User Interface code. There is a good article here that discusses UI patterns, and a previous post of mine that contrasts the MVP pattern with a pre-release version of the ASP.NET MVC Framework. The Web Client Software Factory (WCSF) uses the MVP pattern, and relies on Dependency Injection to wire up the class dependencies.

The following diagram should help you visualise how MVP is put together;

Note that each Presenter has exactly one View, and each View has exactly one Presenter. There is one Model for the whole application (ahem, see later posts on modularity J).

Let’s consider each item in turn.

Model

The model is often misunderstood. It sounds like it should just be data, but then where does my business logic sit? Well, I see the model as representing the whole of my business logic – entities, workflows, and components. It is the window into the real non-UI part of my application. Sticking to our standard architecture defined in the introduction post, the model should only expose business logic components. It should not surface data access components, web service proxies, or other private classes that are further down the architecture stack.

Note that in much of the WCSF documentation the “Model” in MVP is silent – mainly because you could argue it isn’t really a key part to the structure of the UI code, as it is business logic. Hence you might see MVP referred to as “the View-Presenter pattern”. It’s the same thing...

We will discuss the model, how to structure it, and how to implement it in later posts, but for now just think of it as a bunch of plain old .NET objects that “do business logic”.

View

A view is used to display data to the user, and therefore in the WCSF is an ASP.NET “aspx” page and its code behind. In the WCSF, this aspx page must implement an interface (e.g. “IHomePage” would define the Home Page view, “HomePage.aspx” would implement it, and it would have a matching presenter named “HomePagePresenter”). The code that exists in this class should be very simple – and should be focussed on two simple tasks;

1. Taking instructions from the Presenter and converting them into ASP.NET calls.

2. Taking events from the user (such as button clicks) and passing them on to the Presenter to field.

Effectively, the view is responsible for translating between the Presenter and ASP.NET concepts.

Note that on the pattern diagram above I really wish I could remove the arrow from the view to the model. This is because when I use MVP I enforce a rule that the View should under no circumstances call directly to the business logic. The only reason the arrow is there is because the view may have read-only access to some business entities for rendering purposes only. This is heading towards the “supervising controller” variant of the pattern described in the WCSF documentation here, which I find to be the only practical way to implement data-binding.

Presenter

A presenter instructs a view what should be displayed and when, and responds to events raised by the view. It should be unaware of ASP.NET concepts. It should also be the class that interacts with the business logic, potentially passing on single or multiple business entities to the view for rendering. In other words, it is the go-between for business logic and rendered UI.

In the WCSF the presenter has a reference to the view as defined by an interface, hence the two-stage and dotted link in the diagram above.

An example

So after all this theoretical talk, let’s see a really simple example of a Model-View-Presenter trio and how they work. Have a look at the following (simplified for clarity) code.

interface IMyView

{

void DisplayText(string name);

}

class MyView : IMyView

{

public MyViewPresenter Presenter { get; set };

public void DisplayText(string name)

{

TextBox1.Text = name;

}

public void ExitButton_Clicked(object sender, EventArgs e)

{

Presenter.OnExit(Page.User.Identity.Name);

}

class MyViewPresenter : Presenter<IMyView>

{

void ViewLoaded()

{

View.DisplayText("Welcome");

}

void OnExit(string username)

{

BusinessLogic.ExitUser(username);

View.DisplayText("You clicked Exit!");

}

What we have here is the following;

1. An interface that defines the operations that our View exposes (just “DisplayText” in this case).

2. An implementation of the view (aspx mark-up omitted in this example). This receives instructions such as “DisplayText” and translates them into ASP.NET concepts – such as setting the Text property on a TextBox.

3. A presenter, which instructs the View what to do during initialisation, and responds to View events (such as Exit). Note that the Exit method calls into business logic and then updates the view.

I hope that is a nice clear simple example of the interaction between the classes.

How do I get my data?

This example contains a really interesting yet subtle point, and that is how to pass data from a view “up” to the presenter. In my code, I make the following call;

Presenter.OnExit(Page.User.Identity.Name);

What this means is that my view is responsible for collecting the relevant data and passing it on to the presenter at the appropriate time. Now this isn’t necessarily wrong, and in many cases is the easiest way to write code – but actually I think it is sub-optimal.

The issue is that we already have an interface defining what our view provides, and I feel that this should really be the contract between presenter and view for as much information as possible. Therefore, I would prefer the following implementation;

interface IMyView

{

void DisplayText(string name);

string CurrentUsername { get; }

}

class MyView : IMyView

{

public MyViewPresenter Presenter { get; set };

public void DisplayText(string name)

{

TextBox1.Text = name;

}

public void ExitButton_Clicked(object sender, EventArgs e)

{

Presenter.OnExit();

}

public string CurrentUsername

{

get

{

return Page.User.Identity.Name;

}

class MyViewPresenter : Presenter<IMyView>

{

void ViewLoaded()

{

View.DisplayText("Welcome");

}

void OnExit()

{

BusinessLogic.ExitUser(View.CurrentUsername);

View.DisplayText("You clicked Exit!");

}

(note: changes are in italic)

What I’ve done here instead is expose the user’s login name as a property on the view, which is defined in the interface that serves as the “contract” between the presenter and the view. I then just raise the “OnExit” event from the view to the presenter, and it is the presenter’s responsibility to extract the information it needs from the view.

This example uses the username, but I would also use it for passing the contents of a textbox edited by the user through to the presenter – expose a property on the view that the presenter extracts the required text from when needed.

I personally think this is more elegant, plus I find it actually helps when writing unit tests. What do you think?

MVP + Application Controller

The final point to make is where the interaction with an Application Controller fits in. Hopefully the diagram below helps;

I believe that, if you go with my preferred approach to the pattern described in a previous post, the presenter should be the only point of interaction with the Application Controller. So in my simple example above, you might have code that looks like this;

class MyViewPresenter : Presenter<IMyView>

{

void ViewLoaded()

{

View.DisplayText("Welcome");

}

void OnExit()

{

BusinessLogic.ExitUser(View.CurrentUsername);

ApplicationController.CompleteExit();

}

The CompleteExit method would more than likely redirect the user to the home page.

Summary

MVP is subject to less confusion once you have ironed out what an Application Controller does, but there are some key points to remember;

1. There should be no logic other than simple data binding or property access in a View.

2. There should be no ASP.NET concepts in a Presenter or the Model.

3. The View must not directly call Model (business logic) methods, but may have a reference to business entities to simplify rendering and data binding.

4. The Presenter should orchestrate the relationship between the View and the Model (business logic).

Following these guidelines should help enable you to unit test your presenters effectively, and should make you smile when you have to make a change to the code... meaning you know exactly where and how to make that change.

Keep listening to hear about modularity in the WCSF, and as always – chip in if you agree, disagree, or don’t think I’ve explained something sufficiently...

WCSF Application Architecture 2: Application Controller

simonince — Fri, 06 Jun 2008 11:59:00 GMT

This article is part of a series;

· WCSF Application Architecture 1: Introduction

So why do we have patterns? I think it is basically to reuse good designs, and to adopt a common terminology when discussing software. But so often the subtleties of patterns are difficult to get right, and this causes confusion when people say “my presenters do X, what do your presenters do?”

I am a little concerned that I’m just going to add to this confusion with these articles. If that’s the case, I never wrote it OK? You didn’t hear it here. It was some other Simon...... J. Joking aside, I think having an open and interactive debate about the different approaches can only help – so please do feel free to comment or blog right back at me!

Anyway, there are two key patterns used in the Web Client Software Factory (WCSF). Application Controller and Model View Presenter. This post examines Application Controller, watch this space for one on Model View Presenter.

Application Controller

To quote Fowler, an Application Controller is used as “a centralized point for handling screen navigation and the flow of an application”. The intention is to abstract the complexity of flow through a set of screens into a discrete controller. Fowler does also suggest that “input controllers then ask the Application Controller for the appropriate commands for execution against a model”. This is where I think the variation arises in the implementation of this pattern.

In most systems today “business logic” is a really fancy word for a bunch of .NET classes that take input from the User Interface, validate it, apply some rules (“business rules”), and bung it in a database, or perhaps chuck it over a service boundary ^*. Occasionally there is a full domain model, but in most cases this logic is pretty straightforward (perhaps a Transaction Script). Therefore I might make a call like this;

MyLogic.SubmitLoanRequest(“Simon Ince”, loanID, loanAmount);

Now this isn’t exactly the Command pattern that Fowler refers to, and although I know some teams use the Command pattern heavily, it is not usually used in .NET land as the primary interface to the business logic.

So if we’re not able (or don’t want) to return the “... appropriate commands for execution...” from the Application Controller, what should we do? Well, I’ve seen three approaches;

1. Use the Application Controller for both Page Flow and as a facade to the Business Logic

2. Use the Application Controller for Page Flow and to supervise Business Logic interaction when required

3. Use the Application Controller purely for Page Flow, effectively as a “slave” class

Option 1: Page Flow plus Facade

Consider the implementation below;

class UserInterface

{

void Page_Load(object sender, EventArgs e)

{

List<string> loanTypes = ApplicationController.GetLoanTypes();

LoanList.DataSource = loanTypes;

LoanList.DataBind();

}

void SubmitButton_Click(object sender, EventArgs e)

{

ApplicationController.SubmitLoanRequest("Simon", 1, 2);

}

class ApplicationController

{

static List<string> GetLoanTypes() {

return BusinessLogic.GetLoanTypes();

}

static void SubmitLoanRequest(string name, int loanid, int value) {

BusinessLogic.SubmitLoanRequest(name, loanid, value);

Navigate("HomePage");

}

Clearly what I have here is as follows;

a) A business logic class that does the work (implied, not typed out for brevity)

b) An application controller that conforms to “Option 1” above

c) A User Interface that uses the Application Controller

Because I am using “Option 1”, my call to get a list of Loan Types from the User Interface must go through the Application Controller to remain consistent with the approach. The submission of the loan request also goes through the controller, which calls the business logic and then makes a decision about page flow.

Let’s try to consider some of the advantages and disadvantages to this approach;

Advantages	Disadvantages
The Application Controller always gets to decide what should happen next. If, for example, a requirements change means a call to GetLoanTypes should redirect the user to a login page, it can do that with ease, and without any other classes changing.	Every business logic method that must be called from the User Interface must have a matching facade method in the Application Controller, even if it doesn’t add any behaviour, and literally just passes on the call (and I’ve seen this a lot). For a large system, this becomes a pain very quickly, from the point of coding effort, lines of code, maintenance effort, unit testing and so on.
There is a very clear pattern of execution – the UI can never short-circuit the approach to call directly into the business logic.	Is it really harder to add a call to the Application Controller if a navigation requirement changes than it is to add a line of code into the controller? I don’t think so, which I personally believe makes this approach overkill.

Option 2: Page Flow plus Occasional Logic Supervisor

Consider the implementation below;

class UserInterface

{

void Page_Load(object sender, EventArgs e)

{

List<string> loanTypes = BusinessLogic.GetLoanTypes();

LoanList.DataSource = loanTypes;

LoanList.DataBind();

}

void SubmitButton_Click(object sender, EventArgs e)

{

ApplicationController.SubmitLoanRequest("Simon", 1, 2);

}

class ApplicationController

{

static void SubmitLoanRequest(string name, int loanid, int value) {

BusinessLogic.SubmitLoanRequest(name, loanid, value);

Navigate("HomePage");

}

What has changed? I’ve removed the requirement for business logic methods that do not have a navigation component to go through the Application Controller. Therefore, my User Interface calls directly to the business logic’s GetLoanTypes method. However, because I know SubmitLoanRequest will require a navigation event, I do call through the Application Controller, which in turns “supervises” calling the business logic and then performs the navigation as before.

Let’s try to consider some of the advantages and disadvantages to this approach;

Advantages	Disadvantages
There is no need for every business logic call to have a facade method in the Application Controller – only those that have a navigation component are needed.	You must decide up front which operations have a possible navigation away from the current page involved.
Flow through the code is simplified – it is more obvious which logic components are used by each UI component.	If you want to change an operation so that it involves a navigation event, you must add code to the Application Controller and tweak your UI code.
	There are now two ways to call business logic – through the Application Controller and from the UI. I think this lacks clarity.

Option 3: Page Flow Slave

Consider the implementation below;

class UserInterface

{

void Page_Load(object sender, EventArgs e)

{

List<string> loanTypes = BusinessLogic.GetLoanTypes();

LoanList.DataSource = loanTypes;

LoanList.DataBind();

}

void SubmitButton_Click(object sender, EventArgs e)

{

BusinessLogic.SubmitLoanRequest("Simon", 1, 2);

ApplicationController.CompleteSubmitLoanRequest(true);

}

class ApplicationController

{

static void CompleteSubmitLoanRequest(bool success) {

if (success)

Navigate("HomePage");

else

Navigate("ErrorPage");

}

What has changed this time?

We’ve now completely removed any interaction between the Application Controller and the business logic, instead letting the UI handle all of this. The controller is purely responsible for deciding what to do next, or “controlling the flow”. Note that I have also added a Boolean parameter purely to illustrate that the controller may need additional state – which we will discuss further shortly.

Let’s try to consider some of the advantages and disadvantages to this approach;

Advantages	Disadvantages
The controller’s responsibilities become very clearly defined and encapsulated.	The Application Controller might need some information from the business logic to make a decision. This could complicate the UI code as it may need to fetch extra data to pass into the controller, or might corrupt our approach by having the controller call into the business logic again!
It is easy to change the way page flow works, perhaps by introducing Page Flow components (e.g. Windows Workflow) because the controller is kept simple and free from other responsibilities.	If you want to change an operation so that it involves a navigation event, you must add code to the Application Controller and tweak your UI code.
There is no need for facade methods to any business logic methods.

So which is best?

This is where I dodge the question. The point is – which do you prefer? I personally prefer Option 3 – I find it keeps the controller’s responsibilities very clearly defined, and when combined with other UI patterns (e.g. MVP) keeps a good balance of code in the right places. I think it also makes testing easier – as you are only testing a controller for flow, not business logic. But I wouldn’t claim this to be the only way.

State

It is worth making a point about state too. An Application Controller needs to make decisions – and these need to be based on what the user did, what they previously did (e.g. if they’ve not logged in, they will be treated differently to a user that has logged in), and what their state means (e.g. if they are under 17, the “CanApplyForUKDrivingLicense” setting would be false). This means the controller needs some awareness of state.

There are three ways to deal with this (you’ll be sick of option lists by the end of this series I’m sure!);

1. Store state in the Application Controller. Expose properties to the UI to get/set state for the current user. This works well, I think, as it centralises your state management. Check out the StateValue<T> and StateDependency features of the WCSF for this.

2. Pass all required state into your Application Controller when you call a method on it. This can also work, as long as you don’t have too much state to be passing around.

3. Have your Application Controller call out into your business logic to get the results of rules based on some state. This is only half a solution, as you will need to know some of the “who” and “what” first anyway. I also think it corrupts the model a little, and so I prefer to avoid this where possible.

In reality, I usually use a combination of (1) and (2) – (1) for real user state, and (2) for the results of business rules.

What is Page Flow?

The final topic to cover is the definition of Page Flow. This is absolutely not the same as “site navigation”. If you try to model the whole of your web site using some kind of Page Flow mechanism, whether that is an Application Controller or otherwise, you will (in my opinion) be creating a tonne of work for yourself. Instead, use the standard ASP.NET navigation controls, hyperlinks, buttons, menus, etc to navigate around your site. This is what they’re there for – and making use of them should keep your pain levels low!

Page Flow is when you have a process in your site that should be completed from end to end – for example, a hotel booking wizard, or a mortgage application. This process might be reached and initiated by a hyperlink from your home page, but once within the process the “back” and “next” buttons would use an Application Controller to determine the steps through the wizard.

If you now take a step back and consider the options presented above, I find that this understanding of page flow is a natural fit with my preferred option 3. Not all pages will be part of a “flow”, so what do you do with the business logic calls then? Should they go through a controller when there is no need for one to assist with page flow? I don’t think so.

Summary

I hope this has helped you think about the Application Controller pattern. Chances are you’ll recognise many of these different approaches, but if you think I’ve missed any shout up – I’m always keen to hear what others are doing, and how successful each approach has been. Stay tuned for a look at MVP!

* over simplification intended!

WCSF Application Architecture 1: Introduction

simonince — Thu, 05 Jun 2008 19:27:00 GMT

[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;

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.

Software Factories 2.0

simonince — Mon, 02 Jun 2008 16:16:00 GMT

If you’ve missed it, there is a new blog dedicated to the Software Factory initiative available here. I’d recommend reading Jack Greenfield’s post entitled “Software Factories 2.0” – in which he covers the current thinking on Microsoft’s Software Factory initiative.

There’s more to come, so sign up to that syndication!

Web Service Software Factory February 2008 Ships!

simonince — Mon, 03 Mar 2008 11:48:00 GMT

Following on from my last post, some top news for Web Service developers - the WSSF February 2008 release has just shipped. Check out the landing page and the community site.

This release adds the all important Visual Studio 2008 support.

Web Client Software Factory February 2008 Ships!

simonince — Fri, 29 Feb 2008 12:47:00 GMT

Great news from Glenn... The WCSF February 2008 release (i.e. 2.0) has just shipped. Check out the landing page and the community site.

This release has addressed many of the top feature requests, supports Visual Studio 2008 and .NET 3.5, includes more guidance, quickstarts and how-to walkthroughs... what’s more, they’ve improved the Composite Web Application Block both by extending it and improving performance, and something I’d not noticed - added support for dependency injection on ASMX Web services.

Great news – and congratulations to the team. Hopefully they’ll have a few moments to relax before the next project J

February 2008 GAX and GAT

simonince — Mon, 18 Feb 2008 11:05:00 GMT

Just a quick note as I’ve had my body pretty much surgically attached to my laptop and various (geeky) books recently... normal service will be resumed soon hopefully J

Anyway, some great news for Software Factories; the Guidance Automation Extensions (GAX) and Guidance Automation Toolkit (GAT) [VS2005, VS2008] February 2008 Release is upon us – see more information on Grigori’s blog.

This includes some bug fixes, improved installation/un-installation support, and of course that all-important support for Visual Studio 2008.

This support of course enables up and coming releases such as the Web Client Software Factory 2.0, as per these comments from Glenn. I’m really looking forward to seeing what the team’s hard work has produced.

WCSF 2.0 Around the Corner

simonince — Mon, 04 Feb 2008 20:48:00 GMT

If you haven’t found it already, Glenn Block has posted a great summary of what is included in the Web Client Software Factory 2.0... which is apparently just around the corner.

And Paulo Morgado has been posting all sorts of demo code relating to using the WCSF bundles.

Sit down and get comfortable for a serious dose of WCSF blog posts from the p&p guys over the coming weeks, no doubt!

The ASP.NET MVC framework, using the WCSF as a yardstick!

simonince — Thu, 22 Nov 2007 18:37:00 GMT

Well, right up until this morning I was planning on blogging about the similarities and differences between the patterns used by the Web Client Software Factory (WCSF) and the up and coming ASP.NET MVC Framework... and then I saw Glenn’s post linking to this great article on patterns used to structure User Interface code. Gutted. Someone has already done it, and what’s worse, they’ve done it much better and more thoroughly than what I had in mind!

Still, I think I can squeeze some mileage out of my thoughts over the past few days... J

Much of this post is my current evolving thinking on the two frameworks, and therefore if you disagree do feel free to chip in and air your views. I’m only specifically comparing against the WCSF because I feel they share many characteristics and address similar problem spaces, and so I think it leads to a good illustration of what the MVC framework might give us, and what you need to be aware of.

My thoughts are also based entirely on what information is in the public domain – I have not had any internal conversations about this, so not only does it “not necessarily represent the views of my employer”, but chances are it will be just plain wrong as CTPs start to appear... so join the debate!

In case you are not sure which patterns I’m referring to, have a quick read of the links under patterns used in the Web Client Software Factory. Specifically we’re interested in View-Presenter and Application Controller. For the MVC framework, there is an hour long video of Scott doing a demo, two posts by Scott here and here, and a good set of notes here.

So how do these WCSF patterns directly compare to those proposed in the ASP.NET Model-View-Controller framework? In the Web Client factory we have a Model (implied, although not named in View-Presenter), a View, a Presenter, and a Controller, and in the MVC framework we have a Model, View, and Controller. So surely the mapping is pretty obvious? Well, it isn’t the simple one-to-one you might think. Here’s what I’ve come up with so far;

Responsibility	WCSF MVP	ASP.NET MVC
Page flow	Controller (single)	Controller (many)
Business logic	Model	Model
Interaction with Business logic	Presenter*	Controller (many)
Presentation logic	Presenter	View (code behind)*
Presentation UI	View	View (mark-up)*

* Two points to note; a) you don’t necessarily have to split a View by code behind & mark-up in the MVC framework, but it seems a logical way to indicate the two roles a page can fulfil; b) many people use the Controller as a facade to the business logic in the WCSF, but the key above is that the instruction to interact with the logic is generally initiated by the Presenter calling a method on the Controller.

So what are these key differences? I’ll try to boil it down to some concrete points.

Controllers

The WCSF tends to have an Application Controller per module, but the MVC framework has many (likely to be one per group of views). So in the WCSF we might have a SalesController that handles all page flow (and potentially business logic interaction) for the Sales module. However, in the MVC framework we might have a PricingController, an InvoiceController, and a CustomerController. Page flow is not necessarily owned by any single Controller.

There may therefore be an opportunity in MVC framework applications to use something similar to an Application Controller to centralise some of the page flow; perhaps by directing all relevant requests to a single Controller Action on an Application Controller to route appropriately. More thought required I reckon!

Entry Points

The primary entry point to the WCSF framework is the View followed by the Presenter. So when the user browses to “~/DisplayProducts.aspx”, the DisplayProducts page is constructed, and the DisplayProductsPresenter is attached to it. This Presenter then drives interaction with the Controller as required to fetch Model data, decide on Page Flow, and so on.

In the MVC framework, the primary entry point is a Controller, as Controllers are URL addressable. So when the user browses to “~/Products/Display”, the ProductsController would be created, and it’s “Display” action would be invoked. This then interacts with the Model and decides which View to use to render the output.

This also drives the relationship between Views and Controllers; rather than there being one Controller for a set of Views (as I approximated above) it is really that an area of functionality has a single Controller – and that Controller may have a set of supporting Views. Therefore the Controller becomes the primary unit driving application functionality, contrary to the WCSF, in which Views are the primary unit that drives functionality.

Of course, the more obvious point to note on Entry Points is the REST-friendly URLs that the MVC framework uses by default. I don’t personally think this adds any significant benefits, but it certainly looks clean and sits with the framework well.

Views

The MVC framework has no separation of View and Presenter. The WCSF splits presentation logic into a Presenter class, and the technology-specific implementation of this into an ASPX page that implements the View definition. Conversely, in the MVC framework all logic to co-ordinate the physical rendering of a result set is contained in an ASPX page.

Perhaps an interesting point here is that the MVC framework’s Controller actually does much of the work that the WCSF’s Presenter does (in initiating interaction with the Model), and therefore MVC framework Views are expected to be significantly simpler than the View-Presenter pairing in the WCSF – pretty much just rendering mark-up and data binding expressions. This simple presentation code is roughly equivalent to what is contained in the WCSF’s View implementation (without the Presenter). So is there any point in separating further “presentation logic” in the MVC framework?

There are two reasons why a Presenter is useful in my opinion;

a) When there is real logic required to decide how to render a View.

b) When this real logic would benefit from Unit Testing.

But the approach encouraged by the MVC framework is to avoid logic in a view, and to stick to pretty straightforward data-binding etc. Instead of one complex View, you may choose to have many simpler Views. For example, if you have a list of products that can be clicked to display details of each, in the WCSF you may implement this as a single View with collapsible sections... hence there is logic to handle clicks, showing and hiding sections, retrieving data, and so on. However, in the MVC framework this would possibly be better implemented as two Views – a list View, and a details View. When the list is clicked, the request goes through to the Controller which renders the result using the details View. This is in fact likely to be necessary to avoid the View from interacting with the Model. (How does it get the individual product’s details if a View can’t interact directly with the Model? It can’t! It needs the Controller to do that first.)

ASP.NET

Something not so obvious is the way in which each framework sits in the ASP.NET runtime. Scott points out the following in this post about the MVC framework;

The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and .Master markup files as "view templates" (meaning you can easily use existing ASP.NET features like nested master pages, <%= %> snippets, declarative server controls, templates, data-binding, localization, etc). It does not, however, use the existing post-back model for interactions back to the server. Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).

In other words, the choice to force all requests through the Controller outlaws the post-back model. In contrast, one of the goals of the WCSF was to support standard ASP.NET functionality wherever possible, to maximise the speed at which developers could get going with it, and allow it to sit well with existing frameworks. This is of course because the WCSF is an accelerator built on the framework, and the MVC framework is just that... an underlying framework.

The choice not to support post-backs in the MVC framework makes absolute sense to produce a more purist application architecture, but it does mean that developers must shift how they think about writing aspx pages.

I’ve mentioned this in a discussion about the patterns because I think it helps define component responsibilities – i.e. a View is much more lightweight in the MVC framework than a classic ASPX page might be. It moves the focus away from building WinForms-like pages to building simple rendering-only templates. I personally believe that if you make this leap, you’re more likely to avoid building monstrous pages that rely heavily on View State, and are difficult to test and maintain...

I also wonder what kind of benefits we may see by not using View State, not going through a page initialisation and load for every post-back button click...

The End... or rather, The Beginning

To conclude, then, my view is that these two frameworks share some common objectives and techniques, and therefore that each can potentially contribute significantly to the other. In the comments on his posts Scott implies a CTP is just around the corner, so let’s look forward to playing with it for real.

WPF Composite Client

simonince — Tue, 30 Oct 2007 13:31:00 GMT

Some top news has been circulating over the past few days or so - Glenn Block has a good summary. Basically there are plans for p&p to produce guidance on building Composite Applications with WPF - new guidance built from the ground up, learning lessons from all the projects and deliverables in this space over the past few years.

I'll be keeping my eye on this one - it sounds very interesting!

Even better, to quote Glenn; "Our target is to have all of the new guidance ship before the end of 2008".