The CurrentUser Property needs to look something like this:

public User CurrentUser
{
    get
    {
        var key = "currentuser";
        if (Session[key] == null)
        {
            Session[key] = /*get user from database some how*/;
        }
        return (User) Session[key] ;
    }
}

This looks simple enough but it is not.  The reason it is not simple is because to get the current user I have to call Membership.Provider.GetUser from the BaseController.  The problem with that is that it creates a dependency on the MembershipProvider class which I don’t want to have, because it will make testing very hard.

One obvious solution was to add the MembershipProvider (which is an abstract class) to the BaseController’s construct and then pass a mocked instance during testing…  The problem with this design is that now my BaseController will be forced to have a parameterized constructor which means that I have to change the code in all the derived controllers to handle that and pass the appropriate instance of MembershipProvider.  Sounds like a code smell.

My solution was to create the MembershipProvider class using my IoC container – in this case, my Ninject Kernel.  This allows me to inject a SqlMembershipProvider in development and runtime and inject a mocked provider in testing.  So the final CurrentUser property looks like this:

public User CurrentUser
{
    get
    {
        var key = "currentuser";
        if (Session[key] == null)
        {
            var Provider
                = (MembershipProvider)
                    Kernel.Get(typeof(MembershipProvider));

            Session[key] = AppHelper.CreateUserFromMembershipUser
                            (Provider.GetUser(User.Identity.Name, true));
        }
        return (User) Session[key] ;
    }
}

If you have been paying attention, you are probably wondering  what is this “Kernel” thing.  Well Kernel is an instance of the Ninject Kernel which itself was injected into the BaseController class like this:

[Inject]
public IKernel Kernel { get; set; }

I could have done this differently.  For example, I could have injected the provider itself using property injection like this:

[Inject]
public MembershipProvider Provider { get; set; }

The only problem is that the provider isn’t needed by all the derived classed and I didn’t want to have a public property in the base class that would hardly be used anywhere else.   On the other hand Kernel could be globally used to instantiate an object.

What do you think?  Is this the way to do it?  Is there a better way?

What do I want from my JavaScript Library?

I want it to be easy (I am not a JavaScript expert)
I want it to be small
I want it to be fast
I want it to be extensible
I want good documentation and/or community support
I want good/easy AJAX support
I want it to be asp.net-friendly
I also want it to be testable (I am using TDD for this project/book)
Open Source would be nice but not required

What are my options?

jQuery – http://jquery.com/
Microsoft AJAX – http://www.asp.net/ajax/
Dojo – http://dojotoolkit.org/
Prototype – http://www.prototypejs.org/
YUI – http://developer.yahoo.com/yui/

This is a shortlist but if you want a more exhaustive, read this.  I only picked these, for the simple reasons that I have heard of them and are somewhat known by the community.

3 days later

It’s been 3 days since I started this post and I have spent all that time playing around with these libraries…  I have gone back and forth in my opinion on which library to use.  I love jQuery’s selectors, ease of use and community support.  Porototype is also very popular and somewhat similar to jQuery; but I would take jQuery over Prototype for the simple reason that I like jQuery.  YUI (Yahoo! UI) library is beautiful looking and very comprehensive.

jQuery

Pros

1. Ease to learn and use
2. Beautiful syntax (the least typing)
3. Great community support and lots of fans
4. Decent Documentation
5. I already own the book
6. QUnit test framework (http://docs.jquery.com/QUnit)

Cons

1. UI isn’t that great
2. Library is not as full-featured without plugins
3. Plugins are somewhat inconsistent in quality depending on the author

Prototype

Pros

1. Good documentation
2. Good community support
3. Lots of books
   1. Practical Prototype and script-aculo.us
   2. Prototype and script.aculo.us: You Never Knew JavaScript Could Do This!
   3. and many more…
4. Great UI with the add-on script.aculo.us (http://script.aculo.us/)

Cons

1. Couldn’t find a testing framework (but I didn’t look too hard)
2. For some purely emotional reason, I prefer jQuery

YUI

Pros

1. Great UI components and styles
2. The best documented library out there, hands down.
3. Distributed hosting of JS files – the script files will be downloaded from Yahoo server, so when my site becomes a mega-hit, it will scale better.
4. Great test framework and test runner – check these demos
   
5. The most complete library
6. PDF cheat sheets for every component

Cons

1. Very verbose – not as elegant as jQuery, but that’s not too hard to fix e.g. I can assign YAHOO.util.Event to a variable $E and use $E as the shorthand.

The rest

I got tired of all the research and decided to wrap it up, so I glanced over Microsoft AJAX and Dojo and realized that there isn’t enough there to justify more research.

The winner…

When I started this post, I was pretty certain my final choice will be jQuery.  Then I started playing with Prototype and it looked really good, which kind of opened my eyes to the need to be open minded and objective.  This lead to a more objective look at YUI and the conclusion to use YUI.  I was very impressed with YUI’s look & feel, extensive documentation, testing framework and the icing on the cake was the free hosting of the JavaScript libraries.  This was a really tough decision because I still love jQuery the best.