Archive for May, 2009

Common Service Locator To The Rescue

Tuesday, May 26th, 2009

After spending the last few hours trying to get an Asp.net MVC site working in medium trust, unfortunately I just couldn’t get StructureMap the IOC container I had decided to use to work, as it appears to call off to some code  deep down in it’s bowels that uses some reflection.

Fortunately we had decided to use the Common Service Locator an abstraction layer over your IOC so swapping out the IOC container with Unity which I know does work in medium trust was a doddle. It’s funny because when I put in the Common Service Locator code I did question its relevance as I could never envisage a reason why I would want to swap out my IOC container.

You live and learn I guess.

Get Free Typemock licenses – ASP.NET bundle launch

Tuesday, May 19th, 2009

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePointASP.NET,MVCWCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you’ll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

One Tangible Benefit of S.O.L.I.D Development

Saturday, May 16th, 2009

So S.O.L.I.D development seems to be the new buzz word at the moment. Now even though we all know that code that is loosely-coupled and highly cohesive leads to greater maintainability and  testability, sometimes it is difficult to tangibly measure the benefits that well structured code can actually bring to the business.

For this post I’m going to mainly concentrate to on the first two rules of S.O.L.I.D development namely the Single Responsibility Principle and the Open Closed Principle

A code base that follows the S.O.L.I.D principles will typically have the following characteristics:

  • A larger number of classes relative to the lines of code
  • Smaller classes
  • Smaller methods

Now when I contrast this with the very typical, legacy code base that I am currently working with things are very different.

  • Far fewer classes relative to the total number of lines of code
  • Large (God) classes
  • Large methods

Where I’m working currently we have a large team working on a number of concurrent projects all working in the same code base. Because of the way our code is structured we typically have a lot of problems merging our code because there are many classes that have to much responsibility, do too much and know about too many other classes. This means that the same classes time after time are modified for different projects. This in turn causes us far more merge conflicts when trying to reintegrate our code. Now problems merging code means longer project timelines and increased costs to the customer.

When S.O.L.I.D principles are adhered to the way we write code is far different. To add functionality to our system we normally try to achieve this by adding new code and classes rather than modifying existing code (Open Closed Principle – where our system is open for extension but closed for modification). Typically because our classes do less and are smaller the chances of two projects working on the exact same class is also reduced, thus reducing the chances of merge conflicts.

S.O.L.I.D and good OO design principles in your code are  not just wooly concepts banded around by academic types but are good sound principles that can save your organization time and money in the long run.

kick it on DotNetKicks.com

Hands off my mouse

Thursday, May 14th, 2009

Roger Johansson at 456 Berea Street posted this article today which reminded me how simple it can be to test your site for certain aspects of accessibility, in this case keyboard navigation of the site.

Unplug your mouse!

Can you still use your site effectively? If not, it is not up to scratch :)
Seriously simple genius. I love that.

Mocking LightSpeed Units Of Work

Tuesday, May 12th, 2009

One of my colleagues asked me the other day how he could mock a LightSpeed UnitOfWork. Apparently he couldn’t find any good examples out there on the InterWeb so I thought I’d post this short code sample to show how its done.

The most important thing is that you should not create your UnitOfWork yourself but use the CreateUnitOfWork() factory method on your LightSpeedContext. See code example below.

using (var unitOfWork = Repository.Context.CreateUnitOfWork())
 {
        var customerOverEighteenYearsOld = unitOfWork
                              .Customers
                              .Where(customer => customer.Age > 18);
       return customerOverEighteenYearsOld.ToList();
 }

Now if we wanted to test this code by mocking our UnitOfWork we can substitute our IQueryable<Customers> with an in memory collection rather than hitting the database directly.

So our unit test setup code would look something like this. The example below uses Rhino Mocks to mock the Unit Of Work.

[SetUp]
public void TestSetUp()
{
         // Customer Collection
         var customers = new List<Customer>{
                                new Customer{Age = 10},
                                new Customer{Age = 18}
                                }; 

         var unitOfWorkFactory = MockRepository.GenerateStub<IUnitOfWorkFactory>();
         var unitOfWork = MockRepository.GenerateStub<CustomersUnitOfWork>(); 

         // Replace the normal UnitOfWorkFactory with our implementation.
         Repository.Context.UnitOfWorkFactory = _unitOfWorkFactory; 

         // Stub the behaviour of our unit of work factory to
         // return our mocked UnitOfWork
         unitOfWorkFactory
                    .Stub(uowf => uowf.Create(Arg<LightSpeedContext>.Is.Anything))
                    .Return(unitOfWork ); 

         // Stub our unit of work to return our in memory customer collection.
         unitOfWork.Stub(uow => uow.Customers()).Return(customers);
}

So all we really need to do is to mock our LightSpeed UnitOfWork Factory replacing the default factory on our LightSpeed Context with our mocked version.  

We can then stub out the Create method on our mocked UnitOfWork factory to return our own implementation of our UnitOfWork (which is also a mock).  

We can now get our UnitOfWork to behave as we want it to without ever having to hit a database.

kick it on DotNetKicks.com

.Net TimeBombHack

Friday, May 8th, 2009

I love this code which I found when digging around in some of Ayende’s source code , so I thought i’d share it with you, but I can’t take the credit for it.

Its called the TimeBombHack class and you can use it for those times when your writing code when you would usually put in a  //TODO:  comment.

However as is often the case sometimes these todos get forgotten and never get implemented and can make it into production. You can put the TimeBombHack into your code specifying a date and message. When the date arrives the code throws an exception, simple as that.

 TimeBombHack.Until(new DateTime(2009, 5, 14), "Add exception handling");

Anyway the code looks like this:


 public static class TimeBombHack
 {
     #region Public Methods

     public static void Until(DateTime expiredAt, string message)
     {
          var hackExpiredMessage = string
             .Format("The hack ({0}) expired on ({1}). You really should fix it already",
                 message,
                 expiredAt);

          if (DateTime.Today > expiredAt)
             throw new HackExpiredException(hackExpiredMessage);
     }

        #endregion Public Methods
 }

kick it on DotNetKicks.com