MemoryUnitOfWork context = new MemoryUnitOfWork();

            Repository<Customer> r = new Repository<Customer>(context);
            r.Save(new Customer(1, "Joe Bloggs"));
            r.Save(new Customer(2, "Joanna Bloggs"));

            IEnumerable<Customer> customers = from c in r.Fetch(null) where c.ID == 1 select c;

            List<Customer> results = customers.ToList<Customer>();

            Assert.AreEqual("Joe Bloggs", results[0].Name);

            DataContext db = new DataContext("Data Source=(local);Initial Catalog=DMGTest;Integrated Security=SSPI");

            SqlUnitOfWork context = new SqlUnitOfWork(db);

            Repository<Customer> r = new Repository<Customer>(context);

            IEnumerable<Customer> customers = from c in r.Fetch(null) where c.ID == 1 select c;

            List<Customer> results = customers.ToList<Customer>();

            Assert.AreEqual("Joe Bloggs", results[0].Name);

IEnumerable<Customer> customers = from c in r.Fetch(null) where c.ID == 1 select c;

function RefineSearchView() {
    var _controller;
}

RefineSearchView.prototype.setRefineSearchController = function(newController) {
    this._controller = newController;
    $("#btnStreetRefineFilter").bind("click", createMethodReference(this._controller, "HandleFilter"));
}

$("#btnStreetRefineFilter").bind("click", this._controller.HandleFilter);

this.element.onclick = this.buttonClicked.bind(this);

RefineSearchController.prototype.HandleFilter = function(e) {
    var searchParams = this._searchController.getSearchParams();
    var locality = this._view.getLocality();
    var town = this._view.getTown();

    searchParams._locality = locality;
    searchParams._town = town;

    this._searchController.setSearchParams(searchParams);
    this._searchController.search();

    this._view.updateFilterStatus(searchParams);
}

 $.ajax({
                type: "POST",
                contentType: "application/json; charset=utf-8",
                data: "{}",
                dataType: "json",
                url: "http://localhost/PrintService/PrintService.asmx/RenderPrintDialog",

                success: function(data) {
                    $("#printdialoginner").html(data.d);
                    $("#printdialog").dialog("open");
                },

                error: function(xhr, status, errorThrown) {
                    alert(status);
                    alert(errorThrown);
                }
            });

• The View knows about the different view types, and knows about UI events.
• The View Types know how to render themselves, but are still pretty "dumb".
  
• The Controller knows about UI events, and things called Interactors, but it doesn't know what Interactors are or what they actually do.
• The Interactors know exactly what is going on, they interact directly with the view type and the server.
  

Make sure you follow the pattern outlined here - http://msdn.microsoft.com/en-us/library/w369ty8x(VS.80).aspx

Making sure that your application is disposing of any unwanted resources has always been part of the ugly plumbing work of writing software.  Although .NET "helps" with this - by providing a non-deterministic Garbage Collector - it can actually muddy the waters a little.  Now, instead of having to implement a Destructor in each class, most of the time you can let the framework deal with it. 

The tricky part - and the reason I'm writing this blog - is remembering the specific scenarios when you need to, and when the framework will take over.

The general guidance is that you only need to implement IDisposable when dealing with unmanaged resources.  This is because the framework has no way of tracking this, and you need to do it yourself.  However, there are other scenarios where you might need more control.

A specific scenario would be if we had a class which had hooked into events provided by a global static or singleton class.  This singleton would likely not be disposed of until the application is shut-down (although obviously every case is different).  Because the delegate keeps a reference to our class, it would keep it alive until the singleton is disposed.  It is highly likely we want to free our class before this.  Whether we do this as part of implementing the IDisposable pattern, or use Init() and Unit() methods, is still up for debate.

In the following scenario, only ListForm and NavBarControl is required to implement IDisposable (because it is a Form):

Because this is a self-contained object graph, once we free our reference from ListForm, the GC will be able to free all the objects within this graph.

HOWEVER, if, say, ListFormController were to hook up an event handler to an object outwith this graph, then we would be in trouble - because it would not be freed and therefore keep it's referenced items alive.

You can find out more about the IDisposable pattern here.

It takes a while to get going after the holidays, but once I had dusted the mince pie crumbs from the thinking cap it was business time.

As you may be aware from previous posts, I'm a regular user of the various flavours of the MVC pattern (MVC, MVP, Supervising Presenter etc.  I'll just refer to it as MVC from now on, even though the exact pattern I'm using may not be that).  The software might take a little longer to construct, but this will pay back in maintainability, testability, legibility and other -bilities.  

The task for today was to apply a user-defined 'mask' over a datasource that was bound to a grid.  In this specific case, we apply the mask to the grid instead of the datasource, but the principles would be the same if our requirements were to modify the datasource in some way.

We have 3 MVC-triads involved, and the associations between which (and classes) are illustrated below:

The 'Super' triad, shown in green, is where it will begin.  The Window will receive the click event to show the Top N dialog, which will notify the WindowController.  The WindowController will then create the concrete TopN View (the dialog), passing this into the TopNController.

When the user clicks the 'Apply' button on the Top N dialog, this will communicate the specified values to the TopNController, which will then modify the PivotViewDef.  Note: The PivotViewDef is stored by the Document, and bound to the GridView by the GridController on instantiation.  We use a simple Observer pattern for this, which means that whenever PivotViewDef is modified, we broadcast this change to any interested parties, which can then take action.

Therefore when the PivotViewDef is modified, it will automatically refresh the GridView.

This is a clean and elegant design, as it removes any logic from the forms.  The inter-dependencies between the various components are also limited, which reduces the complexity.  And because the TopNController only communicates to the view via an interface, it is inherently unit-testable.

One of the most valuable lessons I ever learned during my time at university, was the methodology of Divide-And-Conquer.  This can be applied to anything, but in Computer Science is vital for dissecting those complex problems into their component parts.

The only problem was that, like a lot of things I did at uni, it wasn't really put into practice once the coursework and exams were over.  When you start work it's all about delivery - you don't have time to really think things through in this way, especially when you only have a couple of days until what you're working on is in the product, finished and looking shiny.

Or at least, you don't think you have the time.  But turns out the lecturers and academics are right after all.  Taking the time up-front to fully understand a component, whether it be for internal use or a UI control, saves a lot of hassle in the long-run.  Think incomplete specifications, unexpected surprises, and debugging particular scenarios during a defect cycle.

I've been thinking about this recently as I have to get to grips with a new control, and slot it into an existing application.  Whenever I start to work with a control that I'm unfamiliar with, I like to build myself a little sandbox and give it a good going over, making sure that I know what's going on in an isolated environment, without having to worry about the rest of the codebase affecting it.   I might not get as much time on it as I'd like, but there's always that balance. 

What this lets me do is get to grips with what I'll be using the control for, how it binds to data, how it can be controlled via it's interface rather than using the 'Smart' Tags to configure it.   

I've been putting this technique through it's paces for a couple of years now, and it's clear when I look back at some older code how much of a difference it makes.  The solutions might take a little longer to develop, but the result is a cleaner implementation, for the reasons outlined above.

If I was President, I'd like to see a lot more of this sort of thing.  Whenever a new component was being developed, it should have an associated driver (prototype/sandbox - call it what you will) which configures and simulates the component in a real-world environment, but completely isolated of other parts. 

Of course, what this ultimately results in is a suite of Unit Tests for your newly developed component.  So this is hardly a revolutionary idea, but supports that we are on the right track.

I'm sure you'll be aware of the different MVC frameworks currently out there on the web.  RubyOnRails, MonoRail, and the new Microsoft ASP.NET MVC framework all claim to accelerate web development by removing a lot of the mundane, monkey-work plumbing involved in creating a web project.

They also provide a clear separation of concerns, by separating the presentation, logic and data-access into discrete layers.  This has the advantage that we can then introduce unit-testing into our web project, and mock any required components.

So far so good, but personally having looked at these frameworks, I can't fit them into any projects I'm working on at the moment.  It seems to me to be a trade-off between how much control I need and how much it conforms to a typical web layout.  But that's maybe because I haven't actually tried them out on anything other than a sample project. 

Having said that I do like what they offer - GETTING THE CODE OUT OF THE PAGE. 

Essentially, I believe we can achieve this and also maintain a lot of the control by using the framework outlined below.

As you can see, we have our MVC-triad, with the Controller at the heart.  The Controller interacts with the View via an interface, with each concrete WebPage having a reference to the Controller.  The WebPage also CREATES the Controller object(s) it uses, passing itself (it's interface) in to the Controller's constructor.   When the User selects something on a Page, the Page then calls the required method on the Controller.  The Controller can then carry out any logic and indirectly navigate to another URL.  It does this via the View interface that it has passed to it in it's constructor.

This example shows how the Controller can be used to control application flow.  The user initiates a command on MainPage, which calls Controller.Do_Command1.  In this method, the Controller would then carry out any logic for that Command, but then wants to move to another page.  The Controller can't do this directly, so calls the Show_AnotherPage() method on IMainPage (the MainPage's view interface).  The concrete MainPage class then redirects to AnotherPage.

This example shows the Controller again controlling the application flow, this time with conditions.  You can see how this could be easily tested via mocking.

Admittedly, this framework still relies on the developer putting in a lot of the plumbing, which has been nicely encapsulated by other MVC frameworks.  However, with this you get complete control over what is happening, and you also get to use the traditional WebForms approach, complete with Viewstate et. al. which is essential for 'legacy' apps.  It also means you can pick and choose the areas in the project where you implement it. 

If I was starting a web app from scratch I'd certainly look into MVC ASP.NET and see how it would work, but if you want the benefits of code separation in your existing applications now, then this framework could be adapted very easily.

EDIT: I'm not sure I really would look into MS' MVC ASP.NET framework any more - I can't see what benefits I would get from it that I can't with this approach.

I've been working on a particularly tricky problem recently, one that has me analysing the Form values collection that is passed in an ASP postback.  Not that difficult in itself, but I don't know what values I'm looking for until runtime!

I ended up encapsulating this parsing logic in a special FormValuesParser class, but once I had finished I couldn't eliminate the bad code smell that was hanging around, and coming from someone who buys the office air-freshener, I had to do something about it.

It was easy enough to see where it was coming from.  The main method in this class, ParseKeyType, was a huge switch statement.  Each case block did more or less the same thing, but had to do it in subtly different ways - for example, parse the formValueKey one way for a Browse type, and a different way for a MultiSelectCheck type.

The code looked like this:

private void ParseKeyType(string formValueKey, KeyType keyType)
        {
            string controlMapKey;
            FormKeyInfo keyInfo;
            switch (keyType)
            {
                case KeyType.Browse:
                  //Perform specific parsing to Get Control Map Key
                  //Get Key Info
                  //if KeyInfo != null
                  //Set KeyInfo.Value
                    //Get key look up in ControlMap
                    break;
                case KeyType.MultiSelectCheck:
                  //Perform specific parsing to Get Control Map Key
                  //Get Key Info
                  //if KeyInfo != null
                  //Set KeyInfo.Value
                    //Get key look up in ControlMap
                    break;
                case KeyType.TextEdit:
                case KeyType.Memo:
                case KeyType.SpinEdit:
                case KeyType.Browse_DropDown:
                case KeyType.DateEdit:
                case KeyType.DateTimeEdit:
                  //Perform specific parsing to Get Control Map Key
                  //Get Key Info
                  //if KeyInfo != null
                  //Set KeyInfo.Value
                    //Get key look up in ControlMap
                    break;
                case KeyType.CheckEdit:
                  //Perform specific parsing to Get Control Map Key
                  //Get Key Info
                  //if KeyInfo != null
                  //Set KeyInfo.Value
                    //Get key look up in ControlMap
                    break;
                case KeyType.TimeEdit:
                  //Perform specific parsing to Get Control Map Key
                  //Get Key Info
                  //if KeyInfo != null
                  //Set KeyInfo.Value
                    break;                    
            }

So trying to fathom what was going on when you have to add a new KeyType in 6 months time was going to be a hassle.

If we apply the Strategy pattern, where we encapsulate the code logic within distinct Strategy classes but provide a common interface, we end up with the following, MUCH more fragrant code:

        private void ParseKeyType(string formValueKey, KeyType keyType)
        {
            IKeyInfoStrategy keyInfoStrategy = null;
            switch (keyType)
            {
                case KeyType.Browse:
                    keyInfoStrategy = new BrowseKeyInfoStrategy();
                    break;
                case KeyType.MultiSelectCheck:
                    keyInfoStrategy = new MultiSelectCheckKeyInfoStrategy();
                    break;
                case KeyType.TextEdit:
                case KeyType.Memo:
                case KeyType.SpinEdit:
                case KeyType.Browse_DropDown:
                case KeyType.DateEdit:
                case KeyType.DateTimeEdit:
                    keyInfoStrategy = new SimpleKeyInfoStrategy();
                    break;
                case KeyType.CheckEdit:
                    keyInfoStrategy = new CheckEditKeyInfoStrategy();
                    break;
                case KeyType.TimeEdit:
                    keyInfoStrategy = new TimeEditKeyInfoStrategy();
                    break;        
            }


            if (keyInfoStrategy != null)
            {
                string controlMapKey = keyInfoStrategy.GetControlMapKey(formValueKey);
                FormKeyInfo keyInfo = GetKeyInfo(controlMapKey);
                keyInfoStrategy.SetKeyInfoValue(keyInfo, formValueKey,
                                                    mFormValueCollection);            

            }
        }

First off, we create an IKeyInfoStrategy interface which contains the common behaviour we have abstracted, and then a concrete Strategy class for each different 'class' of KeyType.

This is a very simple example, but you can see how it will scale and lead to much easier-to-read code.