Part One
Part Two

In the last instalment we finished up with a suite of passing tests. However, we’ve yet to produce anything remotely usable so lets continue by reaching down further and driving out our services/persistence. We’ll start by writing the following test:

We’ve meddled with our test setup a little to introduce the MockRepository for mocking out our PostController’s new dependency on the IBlogPostService. Our test now calls the AddPost method on our service interface and sets up the resulting AddPostResponseDto. Running the test produces a bunch of compiler whinging so we best implement the newly introduced bits:

These are the only changes and additions we’ve made in order for the tests to compile and run. Running our test now produces the following result:

As we’ve yet to modify the PostController.Save(…) call to include a call the newly introduced IBlogPostService dependency. Lets go ahead and do this now:

We’ve now included the call to our newly introduced service and we set the responseMessage if the response is signaled as successful. Lets run our test now:

It works, ship it! Actually no, again we’re pretty low on actual functionality right now. Remember we’ve yet to actually drive out any implementation of the IBlogPostService interface as yet and I expect that the acceptance test will fail horribly since we didn’t wire up the necessary container configuration either. Lets go ahead and run the whole test suite and see what gives:

In the brief moments the browser appears during the test we can see the following:

Hmm, as I predicted earlier our application fails to run due to the lack of proper container configuration. Before we can do this we need to implement the IBlogPostService interface somewhere. We need to write a failing test to begin our foray into the implementation of a BlogPostService:

Lets create the BlogPostService only performing the steps necessary to pass the test above:

Run the test:

Now we have a working BlogPostService we can now wire up our container configuration to pass the acceptance test:

Now running the full suite of tests produces the following:

Our tests pass!

That’s it for this post. I’ve checked in the latest changes to the repository. In the next post we’ll continue our efforts and begin to implement validation on our screen-bound DTO’s.

Google code hosted project: http://code.google.com/p/mr-blogengine/

EDIT: This is hosted in a google code project accessible from here: http://code.google.com/p/mr-blogengine/

This is the first of a series of posts I’m penning where I’ll be incrementally developing a basic blog engine running on the Castle trunk and developed wholly test first.

Each new feature or addition will be described by simple narrative, followed by some testing/coding from the UI (or controller in this case) down to the database.

I’ll be using much of the Castle stack goodness including Monorail, Windsor and ActiveRecord. Unit testing with Mbunit and acceptance testing with Watin.

My aim with this series of posts is to demonstrate the power of the Castle stack, combined with TDD and the slow, incremental addition of features. After each post I’ll check in my latest changes which will after a clean build will result in a fully working system.

I’ve completed a small amount of scaffolding up-front for brevity:

• Castle built from trunk
• Solution and project structure
• Basic configuration of Monorail and Windsor

As you can see from the right, our solution consists of three projects. The core project will hold our domain model, interfaces, services and application code. There is a test project for both our unit tests and acceptance tests, and finally we have the web application project holding our controllers, views and static content. I’ve put together a basic layout and stylesheet that serve our needs for now. This will be added to as our blog engine matures.

Although we have no concrete examples as yet, the controllers, services, facilities and configuration properties are configured through Windsor XML configuration files in the web project. We’re running on a Castle build I ran locally after checking out the trunk some point over the last couple of days.

It will be interesting to see how our initial design adapts as required when features are piled on during the later stages of development. I’ve not got any specific plans on how long this series will go on for although I am considering moving my blog away from WordPress and will most likely host under the very blog engine I’ll be creating. Good times! Anyway enough of this, lets move on to the first iteration.

Iteration 1: Create a Post

For this iteration we will build our first cut at the blog post authoring screen. This comprises a very basic form allowing the author to specify the title, short description and full content of the post. I think you’ll agree that what we’re building in this iteration won’t serve as a fully powered blog engine any time soon, but lets restate our initial aim here: to incrementally build and adapt our system as new requirements and features emerge. With that said, lets get on to building our first feature!

Our first test:

From our basic requirement we’re now driving out the PostController. This test simply gets our controller into a good state for testing, handily provided by Monorail’s BaseControllerTest and our first test method asserts that when the Add action is called on our controller the correct view is rendered. As you can see from the grab above there is a lot of red code. Resharper is highlighting the members we’ve yet to implement. I attempted to run this test but the compiler chokes. Time to do what we need to pass this test:

Well that was simple enough. Lets run our test and see the result:

As expected, the test now passes. However, there are some serious issues with our controller and the related Monorail configuration:

1. The controller has no associated layout.
2. We’ve yet to create the requisite view: Add.vm.
3. We’ve not added the Windsor XML configuration for our controller.

Before we can do anything to remedy the issues above we’ll need to write a failing test. I’m going to use Watin to create a test which flexes Monorail a little more. Currently our only test relies heavily on most of the controller dependencies being stubbed/mocked out by the BaseControllerTest class. We’ll need to test through the browser to ensure our controller and view/layout are wired up correctly:

As you can see above we’ve crafted a very simplistic test which asserts that the text “Ben Lovell’s Blog” is found in the browser at the specified URL. Note also that our test assumes the application is running at localhost on port 16489. I’ve configured this in the web application properties so we just need to ensure that the VSNET web development server is running on this port for our application. Lets run the test:

As expected it fails. To pass this test we need to perform the three steps mentioned earlier. To do this we first add the Layout attribute to the controller and specify the default layout, the contents of which are shown here:

Next we create an empty view: Add.vm in the views/post folder, and finally we wire up the XML configuration for our controller in the controllers.config file as shown below:

Lets try and run the test now:

Now we’re making progress! Lets extend our test a little more now. This time we will find the title, description and content fields, enter some values and submit the form. Asserting that the confirmation message was displayed telling the user their post was saved:

A few things have changed here: we’ve altered the naming of the test to clarify intent, and as mentioned previously our test will enter some values into our form fields and submit the form. Our last assertion is checking that the correct confirmation message is displayed. Now we could argue that the setting of the description and content is superfluous in this test as the outcomes aren’t asserted. But, the effort required to implement those fields is minimal and highly unlikely to impact on any existing code/tests (i.e. none!).

Lets run the test and see the outcome:

Our test complains that the “Add Post” text was not found. Lets go and fiddle with our view:

Good to go, lets run the test:

Hmm, the first two asserts are passing but now we’re failing on unfound input: post.Title. Time to add the form and fields to the view, we’re going to make a slight jump and include the description and content inputs in our view also:

Re run the test:

It fails as we have yet to create the save action on the controller, and also the nonexistent action doesn’t display the required confirmation… For obvious reasons.

At this stage I’m going to wrap this up for now. Part two will follow over the next couple of days. Stay tuned!

An interesting discussion was brought up in one of the ALT.NET groups regarding the use of DTO’s in the presentation layer that I had to chime in on.

I’m a strong advocate of message passing from the UI to your services for several reasons:

1. Test driving from the top-down is my favoured approach when developing web applications. I’ll start by writing a failing test for my controller (you should know by now I use Monorail ). Then I’ll stub out any dependencies, these usually being service interfaces which accept and return simple DTO’s with absolutely no behaviour. Stubbing out the services allows you to return dummy data very early on in your development. The nice thing about this approach is you can get a working UI together very quickly and then drive out the development of each layer until you hit your domain model. From which point you can then wire-up your real service and repository implementations and satisfy your acceptance tests end-to-end. Now I’m not suggesting that this approach isn’t possible without DTO’s but it makes it a heck lot easier in my experience.
2. DDD aggregates by their very nature are composed of behaviours you don’t want to pass into your UI. Using DTO’s for binding into your UI keeps things nice and lightweight. Cohesion is high as the DTO’s are created for a very specific purpose, usually to satisfy a particular screen or UI workflow.
3. I had made the rather nebulous statement that the use of DTO’s insulates your UI against changes in your domain model. Quite rightly somebody replied saying that this was all relative and there are many means to insulate against change. Of course, I wholeheartedly agree but in my defence I was replying to the OP from my iPhone. Now for me to explain this a little… Unless you’re using query projections (a la NHibernate) you’ll be mapping from your domain entities to specific DTO’s using some kind of mapper class. Your mapper probably depends on the interfaces of your particular domain entities and the implementation of your DTO’s. I say implementation as I drive out the mapping using state-based testing, which of course makes perfect sense when mapping from one state to another! Using DTO’s means our controller has a nice seam between itself and the services through their interfaces thus the controller (read: UI) has no knowledge of the domain model at all. Any changes to the domain model are catered for by changing the mapper specific to the affected messages. I won’t get into versioning messages, mainly because I haven’t got the time or inclination
4. I’ve always thought (and I read this somewhere I think, but can’t remember where) that a sign of a well designed architecture, among other things of course, is the ability to replace the UI and have everything function correctly. Now it was probably more poetic than that but essentially what this means is your UI should have absolutely zero dependencies on anything below your service interfaces. Using DTO’s and message passing means the only work your controllers are doing is scraping the request, passing your message to a service and binding the response. I’ve demonstrated this in systems I’ve developed by providing an API (which can be considered another UI if you squint a little and look sideways) which is comprised of exactly the same service calls and DTO’s my web UI is using.
5. My last point isn’t specifically tied to the use of DTO’s but more based around messaging architecture in general… What this gives me from the very beginning (i.e. the first test) is a nice basis for distributing my architecture. Our services can be hosted on an application server separately from our web application  or preferably located transparently via a message bus which brings in a whole heap of nice side-effects…

So in summary you can see I’m a big fan of the domain model in my services, mapping to and from DTO’s in my UI. What is your favoured approach?

My plan is to build a basic blogging engine using Castle Monorail, Windsor, ActiveRecord and developed with DDD & TDD. I’ll screencast the whole procedure from start to finish, outlining the basic story or stories for each screencast episode and then go ahead and implement those stories.

Due to the (potential) size of this I’ll no doubt split this up over many screencasts – probably weighing in at around an hour or so per piece. Production values will be conspicuously low of course and the screencasts are not necessarily meant to serve as an educational tool, more a window into my usage of tools & techniques.

I’ll spike out the solution bootstrapping and structure before the first screencast rather than bore you with the requisite stuff. Anyway, expect the first bunch of stories to appear some point early next week…

Dependency Injection (or IoC) is a practice I apply when designing software. It enables enforcement of the Single Responsibility Principle and also has the added side effect of producing more testable code.

Scott Bellware has posted an excellent write-up on dependency patterns and it got me thinking about my favoured approach with dependency injection and how the Castle Windsor container provides that for us. I favour constructor based DI as it enforces the fact that your class must be wired up during initialisation. It makes your dependencies highly visible and as Scott mentions – goes some way to producing a self-documenting API.

Some of the common alternatives, or perhaps complimentary approaches include resolving dependencies from the container or service locator hidden in the constructor (dirty), or the provision of property setters for your dependent interfaces. Of course providing getters (or at least public getters) is a no-no as you would be exposing your dependencies to consumers thus violating encapsulation. But I guess this goes without saying?

Thankfully, Monorail controllers and their dependencies can be wired up using constructor based DI via RailsFacility and Windsor integration. Take the following example:

ContactController in the diagram above is a simple Monorail controller that depends on the IContactService to carry out most of its work. Stemming from there the IContactService implementation has dependencies on IContactRepository and an external library (from NSpectre) interface IValidatorFactory which is created using the Windsor factory facility and some custom factory code, but more on that later… As you can see from the model, the dependencies are injected via constructor arguments.

Using the RailsFacility is fairly simple, rather than me explaining it I’ll point you to the docs here. Once you’ve got the facility and container set up, you simple declare your controllers and their dependent components via configuration:

<component id="contact.controller" type="Campaigns.Controllers.ContactController, Campaigns.Controllers">
      <parameters>
        <mailTo>benjamin.lovell@gmail.com</mailTo>
        <subject>Contact message from Website</subject>
      </parameters>
    </component>

I’ve explicitly declared some of the required values for the ContactController constructor above. Just as reminder the signature for ContactController  constructor:

public ContactController(IContactService contactService, string mailTo, string subject)

When the ContactController is wired up by windsor the IContactService contactService argument is resolved to the following service configured in my components.config file:

<component id="contact-service"
               service="Campaigns.Core.IContactService, Campaigns.Core"
               type="Campaigns.Services.ContactService, Campaigns.Services">
    </component>

Of course, ContactService also joins in the fun and has its dependencies injected via the same means:

<component id="contact-repository"
               service="Campaigns.Core.IContactRepository, Campaigns.Core"
               type="Campaigns.Repository.ContactRepository, Campaigns.Repository" />

Windsor detects that the ContactService constructor takes a IContactRepository argument and resolves this automatically.

Now for the keen-eyed among you, and going back to my point earlier regarding the IValidatorFactory dependency… This is resolved using the natty Windsor factory facility, the best explanation of which is here. In my configuration I state that IValidatorFactory dependencies should be resolved via my custom factory code:

using NSpectre.Core;
using NSpectre.Core.Configuration;
using NSpectre.Core.Implementation;

namespace Campaigns.Core
{
    /// <summary>
    /// Factory for NSpectre validators
    /// </summary>
    public class NSpectreFactory : INSpectreFactory
    {
        #region Fields

        private readonly string xmlEmbeddedResourcePath;
        private readonly bool saveGeneratedCode = false;
        private readonly string path;

        #endregion

        #region Constructors

        /// <summary>
        /// Initialises the factory with the embedded resource path.
        /// </summary>
        /// <param name="xmlEmbeddedResourcePath">The path to the embedded resource.</param>
        /// <param name="saveGeneratedCode">Save the generated code</param>
        /// <param name="path">The path to save the code to</param>
        public NSpectreFactory(string xmlEmbeddedResourcePath, bool saveGeneratedCode, string path) : this(xmlEmbeddedResourcePath)
        {
            this.saveGeneratedCode = saveGeneratedCode;
            this.path = path;
        }

        /// <summary>
        /// Initialises the factory with the path to the NSpectre configuration embedded resource.
        /// </summary>
        /// <param name="xmlEmbeddedResourcePath"></param>
        public NSpectreFactory(string xmlEmbeddedResourcePath)
        {
            this.xmlEmbeddedResourcePath = xmlEmbeddedResourcePath;
        }

        #endregion

        #region Properties

        /// <summary>
        /// Gets the path to the configuration embedded resource.
        /// </summary>
        public string XmlEmbeddedResourcePath
        {
            get { return xmlEmbeddedResourcePath; }
        }

        /// <summary>
        /// Gets a flag indicating whether NSpectre should save the generated code.
        /// </summary>
        public bool SaveGeneratedCode
        {
            get { return saveGeneratedCode; }
        }

        /// <summary>
        /// Gets the path to save the generated code to.
        /// </summary>
        public string Path
        {
            get { return path; }
        }

        #endregion

        #region Methods

        /// <summary>
        /// Creates the validator factory
        /// </summary>
        /// <returns>The validator factory, initialised</returns>
        public IValidatorFactory CreateFactory()
        {
            IConfigurationReader reader = new EmbbeddedXmlResourceConfigurationReader(xmlEmbeddedResourcePath, new NullLogger());
            Initialiser initialiser = new Initialiser();

            if (SaveGeneratedCode)
                return initialiser.CreateValidatorFactory(reader, saveGeneratedCode, path);
            else
                return initialiser.CreateValidatorFactory(reader);
        }

        #endregion
    }
}

The custom factory is hooked up using the following configuration:

<component id="nspectre.factory"
               service="Campaigns.Core.INSpectreFactory, Campaigns.Core"
               type="Campaigns.Core.NSpectreFactory, Campaigns.Core">
      <parameters>
        <xmlEmbeddedResourcePath>Campaigns.Core.Model.NSpectreValidations.xml, Campaigns.Core</xmlEmbeddedResourcePath>
      </parameters>
    </component>

    <component id="nspectre.default"
               type="NSpectre.Core.IValidatorFactory, NSpectre.Core"
               factoryId="nspectre.factory"
               factoryCreate="CreateFactory" />

You really notice the effectiveness of this approach when adding new controllers to your project. You simply add the controller code, define its dependencies in the constructor and add the configuration for the controller to your controllers.config file and everything is resolved and injected for you at runtime. Very nice indeed, I’m sure you will agree!

Testing is made easy by providing dynamic mocks. To make this an even nicer experience take a look at the AutoMockingContainer from the nice folks at Eleutian!

To wrap up I have to say: Castle really does kick the llama’s ass.

The monorail pipeline is modeled around a key set of services. This allows a certain amount of flexibility when acquiring resources or using dependent services such as email sending, scaffolding support, controller factories and the like.

Upon initialization of the monorail framework these services are defaulted to monorail provided implementations based on the existence (or non-existence) of service configuration in your web.config file.

This is particularly handy for mocking out infrastructure during automated acceptance testing. Emailing is a good example of when you might want to do such a thing. To provide a mock service for email sending you simply add the following into your web.config:

<services>
  <service
        id="EmailSender"
        type="Castle.Components.Common.EmailSender.Mock.MockEmailSender, Castle.Components.Common.EmailSender" />
</services>

You could of course provide your own mock implementations if necessary.

To provide dynamic mocking for unit testing you should mock out the RailsEngineContext and return an IEmailSender implementation (or dynamic mock) by setting up an expected return on the IRailsEngineContext.GetService call:

Expect.Call(context.GetService(typeof(IEmailSender))).Return(emailSender).Repeat.Any();

I was asked to produce some templates for generating (or alter some existing ones if I could find them) an ActiveRecord enabled domain model from an existing database schema. It got me thinking…  I don’t agree with code generation in the domain model.

Why I hear you ask?

Unit Testing & TDD

Generating the domain model in one fell swoop means you need to go back and retrofit your tests. This approach sucks for several reasons…

• Assumes you know enough about the domain to be making all your design decisions up front
• The process of TDD ensures OO principles are adhered to (or at least easier to adhere to). Code generation assumes a certain amount of inflexibility in the produced code. You don’t get the chance to special case and drive out design by actually consuming the code during design
• It generally doesn’t get done. Show me a developer who said they would “add the tests later” and actually did

The learning process

The code is being generated to make up for a lack of understanding of domain driven design and more importantly ActiveRecord/NHibernate by some team members. This is simply throwing more wood on the fire. I’ve said it before, nothing beats experiential learning. Give those developers the guidance and support they need to enable them to make design decisions and understand the technologies they’re using. As Ayende said:

…if you need to invest a week in your developers, you will get your investment several times over when they produce better code, easier to maintain and extend and with fewer bugs

Backwards thought process

I might not articulate this point particularly well, but still  I sense there’s something not quite right about producing a domain model from a database. The object model should facilitate the relational model. Sure, not every system has the luxury of a green-field relational data source… But those that do are better served by a relational model that serves the domain model. Told you I wouldn’t articulate this very will didn’t I?

I’m not saying I don’t advocate code generation. It just needs to be applied liberally. Generation implicitly (and by its very definition) produces boiler-plate code. Boiler-plate code has no place in the domain model.

An example project I put together recently highlighting recommended baseline architecture has got me thinking about the best approach to domain driven design and incorporating the Domain Model.

The domain model dictates that your entities encapsulate business logic. In facilitating such a requirement your model classes stray from the traditional POCO principles and can end up incorporating infrastructure artifacts such as persistence code and the like. The extreme end of this is being something like an ActiveRecord enabled model – whereby your ORM mappings are essentially C# properties adorned with attributes. This approach has a nasty whiff of Code Smell to me. Other evidence of this can include:

• Having to derive from special classes defined in your ORM framework
• Implementing special logic or types defined by your ORM framework
• Redefining object identity for ORM purposes
• Adding references to libraries required by your ORM framework

A concrete example of this is when trying to serialize entities from an NHibernate and lazy-loading enabled domain model. Due to the cruft required by NHibernate when proxying lazy-loaded collections, certain un-serializable types are introduced. Of course, the way around this side effect is to create Data Transfer Objects and move your data across the wire in this manner.

When layering in application design, the domain model naturally falls into the vertical. When enforcing strict layering the Anemic Domain Model is the only (simple) approach worth considering. The anemic domain model describes a collection of entities exhibiting only data. They can exist outside of an ORM context and depend on fewer packages. Rather than perhaps exposing static methods on your model classes i.e:

Publisher publisher = Publisher.GetById(id);

The danger of this approach is that data access occurs wherever methods on the domain model are invoked. Also, does the domain model have much use if not enforcing the business rules in the domain? After all, the domain model is rarely, if ever a candidate for reuse. I certainly can’t think of any case where it would be.

The alternative is to move those responsibilities out into some form of repository, for example:

Publisher publisher = DefaultRepository<Publisher>.FindById(id);

And in doing so you remove all your persistence concerns from the model. The entities then simply become dumb data holders and any persistence occurs only in the layers you allow it to.

I’m still not sure whether I prefer the former or the latter. DD purists will of course advocate the former, however my experience has been firmly around the latter approach. Can anyone help me decide?

Ok so in the last post I talked about some of the more obvious issues I have with ASP.NET and web forms development. Thankfully, the Castle Project’s MonoRail framework goes some way to alleviating that pain.

The Positives

MVC, MVP, ABC easy as 123…

Under the covers, MonoRail is a full MVC compliant framework essentially comprising a front controller sitting over the ASP.NET infrastructure intercepting specially formed URI’s. The HTML ends up in the browser via your choice of view engine, with NVelocity (a fork of the Jakarta Velocity port) the default and most accessible, Brail being the Boo dynamic language and most performant option and of course a cruddy web forms engine too which nobody should use. I’ve been comfortably using NVelocity for a while now, and provide testament that its not difficult to pick up.

The controller code orchestrates the flow of logic through the application and rails URI’s map nicely to actions on the controller which are ultimately public methods on the controller class itself. All nice and easy. Actions exposed on controllers derived from the magical SmartDispatcherController can translate posted form values into domain model objects for you by simply adding the DataBind attribute to your action’s argument list:

public void Save([DataBind("publisher")] Publisher publisher)

In the above example the publisher argument is passed into the Save action fully constructed via the form or query string values posted! This saves on the usual binding and scraping stuff you normally do in web forms and which almost always ends up sitting in the code behind untested. Note: the databinding stuff is of course very flexible and my example above just touches on the possibilities.

ActiveRecord

The model can be supplied with an ActiveRecord enabled domain model. This of course abstracts away NHibernate behind the scenes. Unfortunately generic collections support doesn’t work right now but I believe that work is firmly underway.

Edit: Generic collections are supported, as long as you’re running from the trunk.

Domain entities are adorned with the necessary attributes defining how their properties are mapped to your data source. This is a departure from the usual hbm XML mapping files but just as expressive.

ActiveRecord also supplies simple validation in the form of special attributes including email validation, regular expression validation and the like.

UI Components

Reusability of UI components is achieved via ViewComponent. These can support nested sections, parameters etc.

AJAX and client scripting support

Built into MonoRail are a number of helpers which allow you to perform the usual AJAX stuff such as calling remote server side methods and callback support, Scriptaculous and Effects2 client side goodness. In fact the helper extensibility is a nice way of adding extensions and wrapping commonly performed functionality in the view.

Convention over configuration

Like RoR, MonoRail prefers convention over configuration. The project structure skeleton is the same throughout all MonoRail enabled solutions. The MonoRail installer also includes a handy templated solution provider for both VS.NET 2003 and 2005 to create the project skeleton and testing is included. Accustomed MonoRail developers can open any solution and just know where things are going to be.

Testability

One of the sore points of ASP.NET development was the unit testing difficulty. MonoRail overcomes this by enforcing the MVC pattern. Controllers are testable classes sitting outside of the usual ASP.NET cruft. There are a number of framework features within MonoRail which specifically aid testing.

Scaffolding

Like RoR, controllers adorned with the necessary scaffolding attributes can automatically produce the basic markup and logic for CRUD operations on your domain model. Handy for prototyping or creating rough-and-ready data entry capabilities in your applications.

Container support

MonoRail supports IoC via the Windsor container. Controllers and their dependencies/parameters can be injected by the container if necessary.

The negatives

MonoRail does have some negatives, which I will mull over:

No 3rd party or ASP.NET web forms controls support

I don’t really see this as an issue but can see that some ASP.NET developers will. Fans of the big UI library packages will complain, but there is this old concept of HTML and it is surprising how flexible it can be Most use of control libraries I have seen has been misguided, by this I mean they’re usually added to a screen just because they can.

The web forms control library isn’t such an issue as things like calendars, grids and the like are not to difficult to duplicate the MonoRail way.

Learning a whole bunch of new concepts/patterns/practices

Most ASP.NET developers are what can only be described as morts. They’re not familiar with design patterns and good practices such as clean separation since they came from either ASP or VB (procedural backgrounds) so this stuff doesn’t come naturally. If you’ve used NHibernate you’ll pick up the ActiveRecord stuff in no time. Learning the template syntax for your chosen view engine is of course another consideration.

Summary

In summary, the benefits of using MonoRail over web forms are clear. Clean separation of concerns, testability, reduced complexity and none of the web form cruft and artifacts. MonoRail won’t suit everybody, but even if you’re happy with web forms it’s definitely worth a look. Personally I think its the only way worth programming in the enterprise with ASP.NET today.

I’ve recently been fumbling around with AJAX and ASP.NET and came across this handy Ajax Patterns repository.

A few of the patterns which immediately stood out to me as the most useful and applicable in my scenario:

Cross-Domain Proxy
Can perform cross-site scripting access (traditionally disabled in most browsers) by mediating through the server.

Submission Throttling
Used to control the amount of requests sent to the server. Rather than responding to every javascript event a local buffer is held and requests are processed at say a 200ms interval.

Take a look…