• Syntax (no <%=):

<% Html.RenderAction<PersonComponentController>(c=>c.List()); %>

• The component does not share ViewData with the er, "calling view"..
  
• You can use a View User Control (ascx) or a View Page (aspx).
  
• By default the component is browsable. You can turn this off using IgnoreRoute:

routes.IgnoreRoute("PersonComponent/{action}");

• On the implicit MVC violations, Phil says:

My personal opinion is that this violates the separation of concerns so important to the MVC pattern. Having a method within your view calling back into a controller in order to render out a bit more view makes me feel a wee bit dirty ;). We’re developing prototypes for an alternative approach. In the meanwhile, I recognize that for a small sacrifice of pattern purity, this method is very useful, hence its inclusion in the MVC Futures assembly, but do understand that you use it at your own risk.

Yeah, and these components need route data and other stuff from the view. It will be interesting to see what they come up with so that I can just drag in my UberGrid and forget about all this coding.  (kidding!) 

For now, this works and it's testable.

It's trivial to test TempData now. This is all that's needed to port the example from his earlier post to Preview 4 (thanks Ben):

[TestFixture]
public class HomeControllerTests
{
    [Test]
    public void IndexSavesUserIDToTempDataAndRedirects()
    {
        var homeController = new HomeController();
        homeController.TempData = new TempDataDictionary();

        var result = homeController.Index();

        Assert.That(result.Values.ContainsKey("action"));
        Assert.That(result.Values["action"], Is.EqualTo("GreetUser"));
        Assert.That(homeController.TempData.ContainsKey("UserID"));
        Assert.That(homeController.TempData["UserID"], Is.EqualTo("user123"));
    }

    [Test]
    public void GreetUserWithNoUserIDRedirects()
    {
        var homeController = new HomeController();
        homeController.TempData = new TempDataDictionary();

        var result = homeController.GreetUser() as RedirectToRouteResult;

        Assert.That(result, Is.Not.Null);
        Assert.That(result.Values.ContainsKey("action"));
        Assert.That(result.Values["action"], Is.EqualTo("ErrorPage"));
        Assert.That(homeController.TempData, Is.Empty);
    }

    [Test]
    public void GreetUserWithUserIDCopiesToViewDataAndRenders()
    {
        var homeController = new HomeController();
        homeController.TempData = new TempDataDictionary();

        homeController.TempData["UserID"] = "TestUserID";

        var result = homeController.GreetUser() as ViewResult;

        Assert.That(result, Is.Not.Null);
        Assert.That(result.ViewName, Is.EqualTo("GreetUser"));
        Assert.That(result.ViewData, Is.Not.Null);
        Assert.That(result.ViewData.ContainsKey("NewUserID"));
        Assert.That(result.ViewData["NewUserID"], Is.EqualTo("TestUserID"));
    }
}

If you actually need to test TempData, you can implement a stub ITempDataProvider and set the TempDataProvider propery on the controller:

public class TestTempDataProvider : ITempDataProvider
{
    public TempDataDictionary TempDataDictionary { get; private set; }

    public TempDataDictionary LoadTempData()
    {
        return TempDataDictionary;
    }

    public void SaveTempData(TempDataDictionary tempDataDictionary)
    {
        TempDataDictionary = tempDataDictionary;
    }
}

(Edited 6/17 with the proper usage from Ben)

Minutes… slow, dreadful minutes.  

I thought it was Resharper’s fault or VisualSVN's but nay.  It’s because I have a large recycle bin, which is fully scanned every time you delete a file.  After I emptied the recycle bin files deleted much faster.

Via Jeff Brown on the alt.net list.

[Tests] are the documentation narrative that will guide future programmers (including yourself when you come back to change this code in three months time and you’ve forgotten what it does). In this case, clarity of intent is found in the quality of the narrative, not necessarily in minimising duplication.

I had a painful experience with DRY tests the other day.  The code looked something like this, but on a larger, more hideous scale:

[Fact]
public void SomeServiceWorks()
{
    using (var service = new Service())
    {
        RunTest(service);
    }
}

[Fact]
public void AnotherTest()
{
    using (var service = Service.MyService)
    {
        CheckProps(service);
    }
}

private static void CheckProps(Service service)
{
    Assert.NotNull(service.OtherThing);
    RunTest(service);
}

private static void RunTest(Service service)
{
    Assert.NotNull(service.Something);
}

So while the code is not clear, it is easy to see what the author was trying to do - keep his tests DRY.  With a lot of tests this makes it very difficult to understand exactly what is going on.

Resharper has a nifty new refactoring that lets us do an Inline Method to clarify these tests.  Just insert at the method name and use the Ctrl-Alt-N shortcut:

I think the resulting code is much easier to read.

[Fact]
public void SomeServiceWorks()
{
    using (var service = new Service())
    {
        Assert.NotNull(service.Something);
    }
}

[Fact]
public void AnotherTest()
{
    using (var service = Service.MyService)
    {
        Assert.NotNull(service.OtherThing);
        Assert.NotNull(service.Something);
    }
}

Database trigger

• See Jon Galloway's post on Auditing with SQL Server
• To generate an audit trigger in oracle you can do something similar.

NH Interceptor (per NH in action and the NH docs)

NH Listener (per the Hibernate docs)

Domain model

Because auditing is a simple application of interceptors there is a lot of guidance online about that approach, and using an interceptor was my first attempt at auditing.

But since the concept of an audit entry is important to the application (and the users!), it makes sense to promote this concept to a domain object.  Reporting is simple and the behavior is easier to manage.  Create a class called AuditEntry (with supporting mapping file) and hang collections of AuditEntry from the entity. Manage this collection in regular behavior:

public virtual void ChangeStatus(Employee employee, DateTime time, OrderStatus status)
{
    if(this.Status != status)
    {
        AuditEntry entry = new AuditEntry(employee, time, this.Status, status);
        _auditEntries.Add(entry);
    }
    Status = status;
}

After having gone down the database trigger path and the interceptor path and encountering friction I now recommend the domain model approach.

As a disclaimer, this is a 55k employee, $11 bil. company.

He said he wanted to organize "communities of practice" (in other words: "networks of experts") so that people interested and expert in various IT subjects could collaborate.  So, for example, there would be a .NET community of practice - a venue, for example, for questions, answers, ideas and experiences to be shared across a globally and organizationally distributed set of company .NET developers.

This was taking some time - his directs are wanting plans, structure, resources and causing delays.

I'm definitely not at the level my boss (3rd removed) is at, nor do I have anything approaching his experience in business or IT, but this struck me as super strange.

We spend millions of dollars on servers, client software and email servers to facilitate these discussions.  I told him he could do it in 5 minutes.  Send an email to the helpdesk requesting that an email distribution list be created, all the developers subscribed to the list.  Then send a note to the list asking everyone to send an introductory email.  If the list gets busy and starts asking questions and sending interesting things, problem solved, task accomplished.  If they don't, then you don't need the community of practice to begin with.  If the list needs to share code snippets or something then they'll find a service or make one.

I'm sure there's more to this than what I understand, but I can't help but wonder if sometimes we think an entire culture needs to change when all it really needs is an email to the helpdesk.

1.  The strategy pattern and others

Chapter 1 of Head First Design Patterns changed my life, and I'm not afraid to admit it.  I devoured the rest of the book.  And then, newly motivated, I read a bunch of other books.  This led to the understanding of other patterns and formalized principles behind OOP, and I gained a base upon which to build more skill.

2. Inversion of control

Tools that transform patterns and principles out of the realm of "elegance" and into the reality of "efficiency" have changed the way I work.

3. Test first

I attended TechEd 2005 and the VS 2005 team was showing off all the new features.  The one that grabbed my attention was the "object workbench" - where you could instantiate objects and play with them in isolation.  "This is great," I thought, "because now I'll be able to see exactly what my code is doing."  I never did play with the object workbench (was it just vapor?), but when I understood later that this vision had been realized already in the form of unit testing I was immediately hooked.

I didn't get it at first.  Like everything else, I had to cut my teeth on it.  I picked some side project and did it with TDD.  I could see my design being different than I would have done it before.  When I went to make a change I was able to do so with confidence.

I test drive almost everything now.  And trust me - I still make many stupid mistakes.  But I understand that's part of the process and it's trivial to fix most of them.

4. Refactoring

Specifically the book.  This is something they don't (or didn't) teach at University.  I can actually use a rigorous process to correct myself!

5. The transition from ADO.NET to ORM

I started with ADO.NET (that's all I knew about) and had my little helper classes and everything, just like everyone else did.  I built some nice active recordy type frameworks for applications I wrote.

I read with great enthusiasm Mitchell's data access tutorials for/from Microsoft and built entire applications with those practices.  I remember cringing every time I had to add a row to a grid or change a screen - the logic was almost entirely in the markup.

I discovered Subsonic, and found it very cool but mostly unusable for several reasons I won't list.

Then I finally got around to reading Billy McAfferty's NHibernate article and stepped through the demos.  What took me so long? I built a sample app to cut my teeth and have never looked back.  Nothing in my career, in my daily tasks, has saved my company more money than my tiny start at understanding NHibernate.  "Finally," I thought, "I can program with objects."  I later tried several other ORMs and shelved them for reasons usually related to friction.

I find it very odd that a lot of guidance from Microsoft (MSDN, the MOC I was teaching as an MCT) centers around object orientation but their data access strategies do not properly support it.  Line of business software is (or has been, for me this is starting to change) all about data - reports, CRUD, legacy data, etc. is involved in almost every feature I deliver to the business.  And if the data access is not OO, nothing is OO.

6. Domain driven design

I have to admit I haven't trudged my way through the entire book.. I have it and I've probably read most of the words in it but I find it a terrible beating to read straight through.  My understanding is therefore limited.  But concepts I have picked up while working on open source and through the community have helped.  I also read DDD Quickly, a summary pdf ebook.  I get the yahoo group messages in my email inbox.

DDD has allowed me to further my application of object oriented programming even more. DDD took what I had learned from NHibernate examples and blew it up to a fuller and richer object orientation.

7. Contributing to open source…

… is one of the most exhilarating things in the world for me.  This is not an exaggeration.. there is nothing like it.  I will never forget my first sweaty-palmed commit, watching cctray like a hawk.

8. Community

I spent a long time just looking for communities without realizing that's what I was doing.  Joining them has elevated my level of discourse (technically), exposed me to new ideas, and introduced me to people I can social network with.  Communities oriented around software user groups, ecosystems and practices are extremely helpful.  Mentors are the best - if you don't have one, get one.  A lot of the time, online, you don't even need their permission.  =)

I have had 5 minute phone conversations with people that have enabled me to jump ahead farther than any one book or principle.

I have always been pretty good at using social networking tools, but now I have a frame of reference that allows me to collect more and better information.

Passion breeds quality.  Passionate people are involved in communities.  Involving myself in communities and surrounding myself with other passionate people has upped my quality.

9. Vertical slices

My professional experience with Agile is limited.  It is not "what we do" on my current team.  Because I usually work on projects by myself and have a large degree of control over the software I produce, I am able to practice pieces of it on a micro level.  The main tenet that I have found to be helpful is to deliver working software early.  Working software is all we have to give, the rest are "gets".  As I work in vertical slices rather than in horizontal tiers, and refactor as I go, my designs are much more robust and flexible.  Frictionlessness is also key.  XP concepts like contiuous integration have really made things much easier than the "Program and pray" method.  Time to login screen is a great metric.

10. The old "The more you know the more you know you don't know" thing

I realize that a lot of these things are so common now and passe (at least it feels that way compared to the level of the people in the communities I listen to).  I strive to be the "dumbest guy in the room."

11. Technical books read different

I have learned that reading technical books is different than reading textbooks and not at all like reading fiction or prose.  I always thought I was a quick reader, but I am not afraid to read a page several times to understand it completely.

12. I do something new in every project

Because of the level of control I have over my projects I require myself to try something new with each one.  This has not caused me more friction - I consider it self guided training.  I spike random stuff more often.

• A crucible is a "severe test" or a "trial" - something through which an idea is passed so that it may be refined, hardened by time, sharpened with experience, and clarified by intellect until it becomes acceptable for practice.
• A good idea has suffered through the crucibles of competition and community, emerged from it more robust, and is elevated within those communities as more optimal than alternatives.
• There's really no other way for non-scientific ideas to prove useful or not.

• Criticism as an aspect of crucible is vital
• Criticism as avoidance of crucible is crippling
• How do we know the difference?
• Crucible criticism: Practiced, intentional, provides alternatives, instructive, cautionary, demonstratable, clear
• Crippling criticism: Defensive, personal, unfamiliar with alternatives, destructive, reactionary, abstract

TreeSurgeon automates the creation of a new project development tree, complete with a VS solution, a test project, a console project and a "core" project.  It also automates the creation of a Nant build file which is set up to generate an Ncover report.

The first thing I wanted to do was add other tools I use in almost every project.  This turned out to be way easy.  Just copy the binaries in the skeleton folder (these get copied to every new tree) and edit the project file templates to add a reference.

Here I added Rhino Mocks:

And added a few lines to the template file:

Easy!  Thanks Bil!

This was straightforward with regards to TDD - I simply mocked the IIdentity and kept going.  When I began implementing dependency injection with an IoC container I struggled until I found a nice way to do this with Ninject.

Ninject offers a pretty cool suite of ASP.NET integration points in the Ninject.Framework.Web namespace.  And without using System.Web.Abstractions, the best way I found to resolve a property of HttpContext.Current (User.Identity in my case) was to leverage a provider.

Update (6/25): Duncan Godwin, in the comments, explained what's perhaps a better way to do this using ToFactoryMethod()

Ninject providers

Ninject providers, IProvider and the simple implementation SimpleProvider<T>, allow the developer to customize the resolution of these hard-to inject objects.  We're talking providers today on the Ninject list.

Here's the one I used to resolve IIdentity:

public class WebIdentityProvider : SimpleProvider<IIdentity>
{
    protected override IIdentity CreateInstance(IContext context)
    {
        return HttpContext.Current.User.Identity;
    }

    public override bool IsCompatibleWith(IContext context)
    {
        return HttpContext.Current != null;
    }
}

Here is sample code like I used in Global.asax.cs:

public class Global : NinjectHttpApplication
{
    // ...

    protected override IKernel CreateKernel()
    {
        var module = new InlineModule(
            m => m.Bind<IIdentity>().ToProvider<WebIdentityProvider>(),
            m => m.Bind<IIdentityService>().To<IdentityService>(),
            m => m.Bind<IDisplayName>().To<DisplayName>()
            );
        return new StandardKernel(module, new Log4netModule());
    }
}

When binding to the provider HttpContext.Current and the user's IIdentity are available.

I have a feeling this isn't the last one I'll use.

Here is sample code with log4net's AspNetTraceAppender turned on (using Ninject logging of course).