try-catch-FAIL

A View Engine for ASP.NET MVC Feature-Based Organized

Matt — Mon, 29 Apr 2013 11:25:38 -1300

I am a huge fan of ASP.NET MVC. It is leaps and bounds ahead of WebForms, and if you’re doing web development on the Microsoft platform, it’s arguably the best overall solution available. But it is far from perfect. One of the things that has bugged me about it since the very beginning is the default organization conventions, meaning separate folders for controllers, view models, and views. These conventions can be replaced though. Read on to see how.

The Default Conventions

If you create a new MVC project using the typical File –> New Project approach, you’re going to end up with something that looks like this:

Your controllers go in one folder, your views in another, and your models in yet another folder. I suppose one could come up with a worse way to organize things, but you’d have to work at it a bit. This approach is akin to creating separate folders for classes, interfaces, enums, etc. Type-based organization flies in the face of good design principles. The Common Closure Principle doesn’t exactly fit here, but I believe the intent does. Instead of organizing by type, I much prefer to organize things by feature, with all the files that are involved in a feature living as close to one another as is possible. Why, you ask? Things that are likely to change together should live close together because it makes navigating (and therefore maintaining) the code much simpler. I don’t want to bounce around between three or four folders while trying to implement a feature, nor hunt around to see where something is used. Instead, I want everything that is related, everything that I should have in my mental context, in one convenient location. I don’t want 50 controllers to weed through, I want to see the one controller that implements the feature I’m working on. I don’t want 100 view folders to scan, I want to see the relevant views sitting right beside my controller. Everything else is just noise.

But, that’s not how MVC works. Out of the box it wants you to have separate folders for each type, with the implementation of each feature spread all across your project. Areas can help a bit with clutter and organization, and Visual Studio and many of the other productivity tools out there try to alleviate some of this pain by making it easy to bounce around, but the core of the problem is still there: we should organize by feature, not by type. Fortunately this is actually quite doable.

A Custom ViewEngine

ASP.NET MVC will actually let us put our controllers wherever we want. As long as it implements IController, we can define routes to it. And models can also live wherever we want. The problem is the views. The default convention is to resolve views using something like “~/Views/{Controller}/{Action}.” It’s a little more complex than that, but not by much. What I’d like is a convention that supports this type of layout:

Notice how everything related to logging in is in the same place: the controller, the models, and the views. I can ignore everything outside of this scope because it isn’t relevant to the feature.

We can take a naïve approach and swap this convention in easily enough, enabling us to do something like “~/Features/{Controller}/{Action}.” Here’s an example from Mohamed Meligy. This approach somewhat works, but it will break down if we ever have a feature folder whose name doesn’t match 1-to-1 with the corresponding controller. And that’s going to happen the first time you have two controllers related to the same feature. Instead, assuming we keep our folder names and namespaces in sync, we can take a more robust approach and use the namespace of the controller to locate a corresponding “Views” folder:

public class FolderPerFeatureConventionViewEngine : RazorViewEngine
{
    //This needs to be initialized to the root namespace of your MVC project.
    //Usually, the namespace of your Global.asax's codebehind will do the trick.
    private static readonly string RootNamespace = typeof (MvcApplication).Namespace;

    private static string GetPath(ControllerContext controllerContext, string viewName)
    {
        //TODO: Cache?
        var controllerType = controllerContext.Controller.GetType();
        var featureFolder = "~" + controllerType.Namespace.Replace(RootNamespace, string.Empty).Replace(".", "/");

        var path = featureFolder + "/Views/" + viewName + ".cshtml";
        return path;
    }

    public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
    {
        var path = GetPath(controllerContext, viewName);

        if (VirtualPathProvider.FileExists(path))
        {
            return new ViewEngineResult(CreateView(controllerContext, path, null), this);
        }
        else
        {
            return new ViewEngineResult(new[] {path});
        }
    }

    public override ViewEngineResult FindPartialView(ControllerContext controllerContext, string partialViewName, bool useCache)
    {
        var path = GetPath(controllerContext, partialViewName);

        if (VirtualPathProvider.FileExists(path))
        {
            return new ViewEngineResult(CreateView(controllerContext, path, null), this);
        }
        else
        {
            return new ViewEngineResult(new[] { path });
        }
    }
}

Another nice benefit of this approach is that it negates the need for areas. I can now organize my features however I want, keeping related files packaged together, and avoid the complexity that comes with areas.

Future Work

This code is definitely not production-tested. I threw it together quickly, and I’m quite sure there are holes in it. It could also benefit from some caching. If you take this and extend it, please let me know, and I will update this post with any improvements that are made.

SpecsFor V3.0 FINAL Finally Available, Finally!

Matt — Thu, 07 Mar 2013 16:54:56 -1300

Well, that certainly took long enough. It’s been nearly a year since I first blogged about SpecsFor 3.0, but I just pushed the final version to NuGet a short while ago.

This release includes a few breaking changes, but for the most part your tests that were created with SpecsFor V2 should continue to work exactly the same as before. Here’s a quick rundown of the changes:

Breaking Change – AfterEachSpec renamed to AfterEachTest – This change was made to better reflect when the callback is actually run: after each individual test case.
Breaking Change – AfterSpec callback method added – You can use this to run any final cleanup after all the tests within a spec have executed.
Breaking Change – Attribute-based method of applying context removed completely – This feature was seldom used from what I can tell, ill-conceived to begin with, and not properly supported by some popular test runners (I’m looking at you, Resharper).
Composable Context System – You can now define standalone behaviors that will be applied to your specs based on conventions you specify. Create a SetUpFixture derived from SpecsForConfiguration to get started.
New extension methods – There are some new methods to help with testing. I’ll run through these in an upcoming post.
Complete internal rewrite – I was never happy with the SpecsFor base class. It started off with too many responsibilities, and it only grew with each release. I’ve refactored and simplified things while doing my best to preserve compatibility with existing tests. Let me know if I failed. :)

In the coming weeks (or months?) I’ll go in-depth with each of these changes here on this blog. I’ll also get the main site updated with better docs and examples. If anyone would like to help, please let me know.

SpecsFor V3 Release Candidate Now Available

Matt — Mon, 25 Feb 2013 13:21:39 -1300

The SpecsFor 3.0 release is nearing completion! The release candidate is now on NuGet. This release further cleans up and simplifies things and lays the groundwork for porting SpecsFor to other testing frameworks.

To try out the release candidate, install the prerelease version from NuGet:

PM> Install-Package SpecsFor -Pre

Since the last preview release, I gutted and rewrote the entire core. This allowed me to drastically improve test coverage of the core itself and will make it possible to reuse much of the code for other testing frameworks (SpecsFor.MsTest, anyone?)

For more about the changes in 3.0, check out my previous post.

Connecting TeamCity to Gitblit

Matt — Tue, 12 Feb 2013 06:11:47 -1300

This post is more of a reference for myself than anything else, but you might find it useful if you have run into security problems while trying to hook TeamCity to a Gitblit server that uses a self-signed certificate.

My team is slowly migrating to Gitblit from Subversion. We’re big on Continuous Integration, so we had to get TeamCity talking with our Gitblit server. This turned out to be a lot more painful than you might think. Gitblit installs with a self-signed certificate. While you should, in theory, be able to swap in a trusted cert purchased from a trusted authority, we were unable to get it to work. So, we are stuck with the self-signed cert. Not the end of the world, but not ideal.

Anyway, the next hurdle was getting TeamCity to communicate with Gitblit. Because we were using an untrusted certificate, we ran into the following exception:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

After a little digging and with some help from this post, I got things working.

First, export the certificate from Gitbit. The easiest way to do this is to navigate to your Gitblit site in Chrome, click the security icon by the URL, change the “Connection” tab, then click “Certificate information.”

This will open a Certificate details window. Change to the “Details” tab, then click “Copy to File” to save the certificate to your computer.

Next, open a Powershell prompt on your build server, and go to your TeamCity installation folder. For our build server, this was c:\TeamCity. In here you will have a “jre” folder where TeamCity installed the Java runtime it uses for hosting the web server and build agent. Copy the certificate you extracted from Gitblit to this same folder, then run the following command:

.\bin\keytool.exe -import -alias git.yourservername.com -file yourcertificate.cer -keystore lib\security\cacerts

When prompted for a password, enter ‘changeit”. Yep, that’s the default password. This will install the certificate into the cacerts keystore (note: if you get a permissions error, try granting your Windows account full permission to the file). After a restart, TeamCity should now be able to connect to your Gitblit server!

A Generic Entity Framework 5 Repository With Eager-Loading

Matt — Sat, 02 Feb 2013 08:56:26 -1300

I’ve been doing some work with Entity Framework 5 lately. Here’s a simple generic repository I created that allows you to “Include” related entities by applying an attribute.

Consider these sample entities:

public class User
{
    [Key]
    public int UserId { get; set; }

    [Required, MaxLength(50)]
    public string Username { get; set; }

    [Required]
    public UserDetails Details { get; set; }

    [Required]
    public SecurityQuestions SecurityQuestion { get; set; }

    [Required, MaxLength(50)]
    public string SecurityAnswer { get; set; }

    [Required]
    public RegisterStatus RegisterStatus { get; set; }
}

public class UserDetails
{
    [Key]
    public int UserId { get; set; }
    [ForeignKey("UserId")]
    public virtual User User { get; set; }

    [Required]
    public int AddressId { get; set; }
    [ForeignKey("AddressId")]
    public Address Address { get; set; }

    [Required, MaxLength(50)]
    public string FirstName { get; set; }

    [Required, MaxLength(80)]
    public string LastName { get; set; }

    [Required, MaxLength(20)]
    public string Phone { get; set; }

    [Required, MaxLength(100)]
    public string Email { get; set; }

    public bool IsDeleted { get; set; }
}

public class Address
{
    [Key]
    public int AddressId { get; set; }

    [Required, MaxLength(120)]
    public string Address1 { get; set; }

    [Required, MaxLength(120)]
    public string City { get; set; }

    [Required, MaxLength(3)]
    public string State { get; set; }

    [Required, MaxLength(20)]
    public string Zip { get; set; }

    public double Longitude { set; get; }

    public double Latitude { set; get; }
}

There’s a simple one-to-one relationship between a User and UserDetails, and a one-to-one relationship from a UserDetails to Address. With Entity Framework Code-First’s out-of-the-box configuration, the User.Details property will not be loaded with it’s parent User object. Neither will the UserDetails.Address property. EF provides the Include method to specify which related entities to pull in when you make a query, but the whole point of a generic repository is that it doesn’t truly know about the entity it contains. We could expose the Include method through the repository, but that’s pretty ugly and is just one more thing we have to think about when utilizing the repository. We could also take advantage of lazy-loading by making the properties virtual, but for simple one-to-one relationships, lazy-loading could result in unnecessary roundtrips to the database.

Instead, I created a simple marker attribute called “Include.” When applied to a property, it instructs the generic repository to include that property when it retrieves the parent object. Here’s the repository:

public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
{
    private static readonly PropertyIncluder<TEntity> Includer = new PropertyIncluder<TEntity>();

    private readonly DbSet<TEntity> _dbSet;
    private readonly RecRentContext _context;

    public Repository(RecRentContext context)
    {
        _dbSet = context.Set<TEntity>();
        _context = context;
    }

    public void Add(TEntity entity)
    {
        _dbSet.Add(entity);
    }

    public void Update(TEntity entity)
    {
        _context.Entry(entity).State = EntityState.Modified;
    }

    public void Delete(object id)
    {
        Delete(_dbSet.Find(id));
    }

    public void Delete(TEntity entity)
    {
        if (_context.Entry(entity).State == EntityState.Detached)
        {
            _dbSet.Attach(entity);
        }

        _dbSet.Remove(entity);
    }

    public IQueryable<TEntity> Query()
    {
        return Includer.BuildQuery(_dbSet);
    }
}

And here’s the PropertyIncluder, which creates and caches a method to apply the appropriate Include calls at runtime:

public class PropertyIncluder<TEntity> where TEntity : class
{
    private readonly Func<DbQuery<TEntity>, DbQuery<TEntity>>  _includeMethod;
    private readonly HashSet<Type> _visitedTypes;

    public PropertyIncluder()
    {
        //Recursively get properties to include
        _visitedTypes = new HashSet<Type>();
        var propsToLoad = GetPropsToLoad(typeof (TEntity)).ToArray();

        _includeMethod = d =>
        {
            var dbSet = d;
            foreach (var prop in propsToLoad)
            {
                dbSet = dbSet.Include(prop);
            }

            return dbSet;
        };
    }

    private IEnumerable<string> GetPropsToLoad(Type type)
    {
        _visitedTypes.Add(type);
        var propsToLoad = type.GetProperties(BindingFlags.Public | BindingFlags.Instance)
                                          .Where(p => p.GetCustomAttributes(typeof (IncludeAttribute), true).Any());

        foreach (var prop in propsToLoad)
        {
            yield return prop.Name;

            if (_visitedTypes.Contains(prop.PropertyType))
                continue;

            foreach (var subProp in GetPropsToLoad(prop.PropertyType))
            {
                yield return prop.Name + "." + subProp;
            }
        }
    }

    public DbQuery<TEntity> BuildQuery(DbSet<TEntity> dbSet)
    {
        return _includeMethod(dbSet);
    }
}

This approach does utilize reflection, but since it caches the method it creates, you only pay a small penalty during application startup.

SpecsFor 3.0 Preview Available on NuGet

Matt — Mon, 07 Jan 2013 17:07:51 -1300

The first preview release of SpecsFor 3.0 is now available on NuGet. This release cleans up and simplifies much of the core while dropping some ill-conceived features, but it also adds a brand new system for composing test context.

To try out the new releases, install the prerelease version from NuGet:

PM> Install-Package SpecsFor -Pre

Be warned that there are several breaking changes in this preview release. Here is (I think) a full list:

ITestState renamed to ISpecs.
Attribute-based method of specifying context completely removed.
Given<TContext> and Given(TContext) methods now execute immediately when called. You no longer have to remember to call base.Given().
AfterEachSpec renamed to AfterSpec to alleviate some confusion about when it is executed.

If you find something else that doesn’t work after upgrade, please let me know. I hate breaking changes, but I feel like these changes are necessary to help SpecsFor grow. Overall, the spec lifecycle is a little cleaner and simpler now with fewer “gotchas” waiting in the wings (such as registering context with Given<TContext> but then forgetting to call base.Given to trigger its execution).

There are lots of enhancements in this release, the biggest of which is what I’m calling “Composable Context.” Composable Context allows you to do things like this:

[SetUpFixture]
public class ComposingContextConfig : SpecsForConfiguration
{
    public ComposingContextConfig()
    {
        WhenTesting<ILikeMagic>().EnrichWith<ProvideMagicByInterface>();
        WhenTesting<SpecsFor<Widget>>().EnrichWith<ProvideMagicByConcreteType>();
        WhenTesting(t => t.Name.Contains("running_tests_decorated")).EnrichWith<ProvideMagicByTypeName>();
        WhenTesting(t => t.Name.Contains("junk that does not exist")).EnrichWith<DoNotProvideMagic>();
        WhenTestingAnything().EnrichWith<ProvideMagicForEveryone>();
        WhenTestingAnything().EnrichWith<MyTestLogger>();
    }
}

Note: full code is available on the Github repo.

These conventions are applied only to tests located within the same namespace as the configuration class or within one of its child namespaces. Composable Context stacks up, too, meaning you can have multiple layers of conventions.

What is Composable Context good for? One possible use is database integration testing:

[SetUpFixture]
public class DatabaseConfig : SpecsForConfiguration
{
    public ComposingContextConfig()
    {
        WhenTestingAnything().EnrichWith<TransactionScopeWrapper>();
        WhenTesting<IRequireDatabase>().EnrichWith<DatabaseFactoryContext>();
    }
}

With this approach, all specs are automatically wrapped in a TransactionScope, while tests that need access to a database need only implement an interface.

Feedback Is Welcome

I would love to hear what others think. I bounced back and forth for quite a while before settling on the changes in this version, and there are many pieces that I’m still not 100% sold on. This is a preview release. This is not the official 3.0 release. If I nuked your favorite feature, please let me know. If there’s something the Composable Context system won’t let you do, describe it, and I’ll see if it can be added.

Using Git for Peer Reviews

Matt — Tue, 11 Dec 2012 14:14:29 -1300

This post is really more of a reference for me than anything else. If you’re using Git (and you should be), and you are doing code/peer reviews (you are, right?), there are a few simple commands that can simplify reviewing a feature that’s spread across multiple commits. Here are those commands.

First you’ll want to see which files were changed as part of the commit. Here’s a simple Powershell command that will do the trick:

git log --grep=<story id> --name-only --pretty=format:'' | 
Get-Unique | 
sort

This grabs all the files that are changed in commits associated to a particular story ID, then pipes them to Powershell to get a list of unique names.

Next, you’ll want to diff the changes to the files. Find the first commit that’s part of the story, grab it’s parent commit hash (the hash of the previous commit), then grab the hash of the final commit. Run this command for each file that you got from the first step:

git difftool <starting hash> <ending hash> <full/path/to/file.ext>

This will fire up your configured diff tool with the changes between the two commits. One thing to note: if there were commits in between that altered the files, you’ll also see those changes.

Happy peer reviewing!

SpecsFor.Mvc 2.0 Released

Matt — Sat, 15 Sep 2012 14:41:07 -1300

SpecsFor.Mvc 2.0 is out today. This release includes drastically improved performance, support for Chrome, and support for the very latest versions of Selenium, ASP.NET MVC, and other libraries.

This is not what I had originally planned for the SpecsFor.Mvc 2.0 release. I had originally planned to have more performance improvements as well as a flexible system for specify conventions. Unfortunately several things have forced me to make breaking changes sooner rather than later. First was the release of ASP.NET MVC 4.0. There were a few changes there that were causing assembly version conflicts for new projects that tried to install the SpecsFor.Mvc package. Second and more importantly though are the changes that have recently been made to Selenium WebDriver.

Selenium is moving towards a model where the core of WebDriver no longer includes the actual web drivers. Instead, they’re counting on browser vendors to supply their own web drivers. This means that, out of the box, SpecsFor.Mvc 1.4 no longer included everything you needed to write awesome end-to-end tests. Because installing SpecsFor.Mvc fresh grabs the latest version of Selenium WebDriver, new projects don’t have the necessary web driver servers to actually execute the tests. You had to go out and download the web driver server for Internet Explorer separately.

I thought long and hard about how to handle this. I don’t like the idea of bundling anything directly within the SpecsFor.Mvc package except for the core components of SpecsFor.Mvc itself. However, the goal of the project is to make it super-easy to start writing end-to-end tests, and having people manually go and install the web driver servers just doesn’t fit that goal. So, SpecsFor.Mvc 2.0 comes with two web driver server executables in the package: one for Internet Explorer (32-bit) and one for Google Chrome (yes, Chrome is now supported). Firefox is still baked in to Selenium Web Driver directly for the time being. That means you can use any of the three major browsers for your tests.

I also made some potentially breaking changes concerning how the web drivers are used. Because the web drivers are now separate executables, it is substantially more expensive to create/recreate one. SpecsFor.Mvc 1.4 destroyed and recreated the driver between every test, but that approach just doesn’t work with the new Selenium WebDriver model. SpecsFor.Mvc 2.0 therefore reuses the same browser window for all tests. This may lead to some unforeseen issues. Testing locally with some of my projects didn’t uncover anything, but still, this was a big enough change that it warranted the bump to “2.0” in my mind. One nice thing about this change is that has a tremendous impact on speed. It used to take 3-4 minutes to run approximately 100 end-to-end tests for one of my mobile apps. With SpecsFor.Mvc 2.0 and Chrome, that same suite of tests completes in approximately 90 seconds.

I may move the web drivers out of SpecsFor.Mvc in the next version. I’m strongly considering putting them in their own NuGet packages that can be pulled in separately. This will make it possible to version the various pieces separately, which will cut down on the size of the NuGet package.

The SpecsFor package also received a minor upgrade to 2.7 tonight. This upgrade does not include any new features, but it was rebuilt against the latest versions of its various dependencies, which should make it easier to pick up and use on new projects.

If you encounter issues with either upgrade, please let me know!

The Decorator Pattern, Done Right, With StructureMap

Matt — Sun, 09 Sep 2012 08:16:33 -1300

One of the cool bits of black magic I showed during my “StructureMapping Your Way to Better Software” talk was an extension method for registering decorators using StructureMap. In this post, I’ll show you how it works.

EnrichWith Says What?

StructureMap actually supports the decorator pattern right out of the box. This functionality is cleverly concealed in plain sight in the EnrichWith method:

var container = new Container(cfg =>
    {
        //...
        
        cfg.For<IProductRepository>()
            .Use<InMemoryProductRepository>()
            .EnrichWith((ctx, r) =>
                {
                    return new ProductRepoLogger(r, ctx.GetInstance<User>());
                });

        //...
    });

var repo = container.GetInstance<IProductRepository>();
//Repo is actually a ProductRepoLogger that wraps an InMemoryProductRepository.

There are several problems with this method though. First, it doesn’t read very well. At all. Especially when you want to apply multiple decorators:

var container = new Container(cfg =>
    {
        //...
        
        cfg.For<IProductRepository>()
            .Use<InMemoryProductRepository>()
            .EnrichWith((ctx, r) =>
                {
                    return new ProductRepoLogger(
                        new ProductSecurityDecorator(r, ctx.GetInstance<IProductAuthorizer>(), ctx.GetInstance<User>()), 
                        ctx.GetInstance<User>());
                });

        //...
    });

var repo = container.GetInstance<IProductRepository>();
//Repo is now ProductRepoLogger that wraps a ProductSecurityDecorator that wraps an InMemoryProductRepository.

Imagine if you added a third (or fourth) decorator, or if your decorators had more dependencies than the simple example above.

The other, bigger problem is that it tightly-couples your configuration code to implementation details of your decorators. What happens if you want need to add an additional dependency to your decorator? You’ll need to go back and update anywhere that you’ve applied that decorator. That really defeats some of the advantages of using an IoC container in the first place.

A Better Way

If the above code doesn’t strike you as something you want to have to look at ever again, I made an extension method for you:

var container = new Container(cfg =>
    {
        //...
        
        cfg.For<IProductRepository>().Use<InMemoryProductRepository>()
            .Decorate().With<ProductSecurityDecorator>()
            .AndThen<ProductRepoLogger>()
            .AndThen<RudeProductRepoLogger>();
        cfg.For<IProductAuthorizer>().Use<ProductAuthorizer>();
        
        //...
    });

var repo = container.GetInstance<IProductRepository>();

The above allows you to chain multiple decorators together cleanly. No more nesting up ‘new’ statements, no more using the context to manually locate dependencies. The decorators are created through the container, so they can take full advantage of dependency injection. That means no more tight coupling between your config code and your decorator constructors!

How Does it Work?

I’m a bit embarrassed to say that it actually took me three attempts to implement this alternative. I tried and failed twice before because I overlooked a simple, obvious approach: register the “inner” instance using IContext.RegisterDefault! The extension method returns a DecoratedInstance that can be used to recursively build up decorator definitions:

public class DecoratedInstance<TTarget>
{
    //...
    
    public DecoratedInstance<TTarget> AndThen<TDecorator>()
    {
        //Must be captured as a local variable, otherwise the closure's decorator will
        //always be the outer-most decorator, causing a Stack Overflow.
        var previousDecorator = _decorator;

        ContextEnrichmentHandler<TTarget> newDecorator = (ctx, t) =>
            {
                var pluginType = ctx.BuildStack.Current.RequestedType;

                var innerInstance = previousDecorator(ctx, t);

                ctx.RegisterDefault(pluginType, innerInstance);

                return ctx.GetInstance<TDecorator>();
            };

        _instance.EnrichWith(newDecorator);

        _decorator = newDecorator;

        return this;
    }
}

What’s It Good For?

The decorator pattern is one of my favorite design patterns. It’s an awesome way to encapsulate behaviors and responsibilities into composable pieces. Here are a few examples using a a simple repository:

Logging

public class ProductRepoLogger : IProductRepository
{
    private readonly IProductRepository _target;
    private readonly User _user;

    public ProductRepoLogger(IProductRepository target, User user)
    {
        _target = target;
        _user = user;
    }

    public Product Find(int id)
    {
        Console.WriteLine("{0} is requesting product {1}.", _user, id);

        return _target.Find(id);
    }
}

Security

public class ProductSecurityDecorator : IProductRepository
{
    private readonly IProductRepository _target;
    private readonly IProductAuthorizer _securityService;
    private readonly User _currentUser;

    public ProductSecurityDecorator(IProductRepository target, IProductAuthorizer securityService, User currentUser)
    {
        _target = target;
        _securityService = securityService;
        _currentUser = currentUser;
    }

    public Product Find(int id)
    {
        if (_securityService.IsUserAuthorizedToAccessProduct(_currentUser, id))
        {
            return _target.Find(id);
        }
        else
        {
            throw new SecurityException("You are not authorized to access this product!");
        } 
    }
}

Caching

public class ProductCachingDecorator : IProductRepository
{
    private readonly IProductRepository _innerRepo;
    private readonly ConcurrentDictionary<int, Product> _cache;

    public ProductCachingDecorator(IProductRepository innerRepo)
    {
        _innerRepo = innerRepo;
        _cache = new ConcurrentDictionary<int, Product>();
    }

    public Product Find(int id)
    {
        return _cache.GetOrAdd(id, _ => _innerRepo.Find(id));
    }
}

By breaking behaviors apart, the original repository remains simple and clean, and the behaviors can be reused with any repository that implements the interface.

Where Can I Get It?

I don’t have a good project for this (yet), so I’ve created a Gist with the required pieces. If anyone has any suggestions on where to put this functionality, let me know. If you want to see a full example, check out my “Learning Structure” map sample project. Questions or comments? Leave ‘em below!

devLink 2012 Wrap-up

Matt — Mon, 03 Sep 2012 08:30:52 -1300

Well, devLink 2012 is over. I got exactly what I expected out of the event: a great time, some new ideas, some great interactions, and some great experience. I see now that I was only partially abusing the Pomodoro technique thanks to @joelcochran, I learned a lot about JavaScript from @ifandelse, and I learned that LINQ really has nothing to do with IEnumerable thanks to an awesome presentation by @kodefuguru.

I had a great time talking about SpecsFor and about StructureMap. My SpecsFor talk was much rougher than any of the other times I’ve presented it, but I’d like to think that I redeemed myself with my StructureMap talk. Thanks, everyone, who provided feedback. It really does help, and it will help me be that much better next time.

Anyway, My code and slides are now online for anyone that is interested (links below). I’ll be posting more details, particularly about some of the StructureMap black magic that I showed, over the coming days (weeks/months). I’m also putting together a refreshed build of SpecsFor.Mvc to address the compatibility problems introduced by .NET 4.5 final, and I’m going to be working on getting some other things posted that I’ve been dragging my feet on. It’s going to be a busy few weeks around here…

StructureMapping Your Way to Better Software – Slides, Code

Integration Testing with SpecsFor.Mvc – Slides, Code