The Web Client Software Factory is a
great software factory from Microsoft Patterns & Practices that enables
you to pretty easily make well-constructed enterprise ASP.NET
applications that can be extended by downstream developers. The factory
contains a lot of stuff - recipes, templates, and a lot of help to
automate some common tasks - but the key item you’ll find in there is
the Composite Web Application
The CWAB allows you to make modular web applications that come together
at runtime to make a nice, seamless experience. It makes it easy to
partition work to various teams but maintain a consistent experience
across the application. It also enforces some nice Model-View-Presenter
separation of concerns when using web forms. Well worth the effort to
The thing is, you may not always want the entire Web Client Software
Factory package when using Composite Web Application Block. There are
two primary reasons you wouldn’t want the Web Client Software Factory in
its entirety, both of which have to do with the associated guidance
- You don’t want the stock guidance packages. That is, the recipes
and templates and other automation items don’t do what you want them
to or are otherwise just something you don’t want. Maybe it’d cost
more to modify the guidance package to do what you want than it
would be to just manually do the work. Maybe you don’t want the
dependencies that the guidance packages assume you want. Whatever
the case may be, you don’t want the guidance packages.
- You don’t want to deal with the developer environment cost.
Having guidance packages that everyone has to use also means you
have one more thing to install on every developer machine. When
upgrades come around, it’s not just dropping an assembly in a folder
to take the upgrade. There’s a cost associated with this, and you
may not want to incur it.
Either way, you may not want the whole thing. What do you get by not
taking it all?
- Slightly ore complex setup.It’s a little more effort to manually
get a CWAB project going if you don’t use the guidance packages. Not
much worse, but this is a legitimate downside.
- Manual control over everything. File placement, assembly
breakdown, naming, etc. You could customize the guidance packages to
do things your way, but it’s not a 20-minute undertaking to do so.
If you’re not going to be adding pages or projects every single day,
it’s probably cheaper to just do it manually.
- Fewer implied dependencies. The guidance packages assume you
want the Patterns and Practices logging, security, and exception
handling application blocks, so there’s a lot of extra stuff that
goes into the templates and such to support that. It can be a pain
to rip all of this out if you don’t want it. The only extra
dependencies you have when you’re using CWAB solo are CWAB proper
- Easier upgrades.When a new version of CWAB comes out, it’s an
assembly update, not something that has to be installed on every dev
- Easier ability to implement standard forms authentication.Out of
the box, CWAB uses the security application block for locking down
page access. If you just want standard location-based authorization
it’s easier to do it without the security application block in your
Here are some general steps to show you how to get CWAB working in your
project without all of the guidance packages. It will help if you’re
familiar with using CWAB within WCSF before you try this out. (I have a
sample later in this article that you can look at for a more concrete
representation. I followed this general process in creating that
- Create a web application project.
- Add references to the Microsoft.Practices.CompositeWeb.dll and
- Add modules (class libraries). In most CWAB projects, there’s a sort
of default “Shell” module that corresponds to the main content of
your site and registers most core services. Add at least this
module. For each module you add:
- Add a reference to Microsoft.Practices.CompositeWeb.dll and
- Add a reference from the web application to the module.
- Add a module initializer class to the module. (A class deriving
- Add a Global.asax that derives from
- For the Default.aspx page (which comes for free with your web
- Break the page up into Model-View-Presenter format with the
presenter and view interface in your “Shell” module.
- Update the page namespace to match the namespace the presenter
and view interface are in.
- Update the page to implement the view interface.
- Update the page to derive from
- Add a Presenter property to the page with a [CreateNew]
ObjectBuilder attribute on it.
- Add the page to the “Shell” module initializer’s site map
- Rinse and repeat for additional pages - put the presenter and view
interface in the proper “business module” and implement the
interface on the page.
There are a lot of things you can do to make this way, way easier.
- Create abstract generic “View” and “MasterPage” base classes.
There’s a lot of common “template” sort of stuff (like the
“Presenter” property on every single web page) that can be removed
by creating some abstract generic classes and deriving from those
- Create abstract module initializer classes for business modules
and foundational modules. Every business/foundational module
initializer is almost identical. You can make it easier to create
initializers if you have some base classes that have abstract
methods you’re forced to implement.
To get standard location-based authorization working with the site map,
you’ll also need to create a custom SiteMapProvider to use in place of
the one that comes with Composite Web Application Block. The reason
you’ll need that is because the out-of-the-box version trims by security
application block settings. To bypass that and use standard
location-based auth, you’ll need a custom provider.
It sounds like a lot, but keep in mind it’s one-time work and once
you’ve got it set up, it’s not all that bad. To get you started, I’ve
got a sample project you can download and see it in action. You’ll need
to get the Web Client Software Factory
because you’ll need the assemblies that come with it (I didn’t include
them in my sample project). Drop them into a specific folder in the
sample project and you should be good to go.
Of interest in my sample:
- The “Framework” module has some example abstract base classes for
views and initializers.
- The “Navigation” module has a service that helps you locate existing
nodes in the site map and contribute to them - something the CWAB
doesn’t come with out of the box.
- I called my “Shell” module “Core” to make sure there was no reliance
on the assembly name “Shell.”
- The “Core” module has a location-based authorization SiteMapProvider
- The sample master pages and style sheets are the ones that come with
the WCSF default site template.
The sample is exactly that - a sample. It’s not really tested (it
works in the context of the sample, though) and I don’t offer you any
guarantees that this will work for you and be totally bullet-proof. Your
mileage may vary, no warranty expressed or implied, etc.