• FubuMVC From Scratch Part 1 – Basic project structure setup
• FubuMVC From Scratch Part 2 – FubuMVC configuration and Controller setup
• FubuMVC From Scratch – Part 3 (Adding View to project)

Persistence is a requirement in virtually every application that we write today, and now the time has come for us to add a persistence model to our FubuMVC app. I know I mentioned moving my samples to the FubuCart source, but I am going to go ahead and implement the persistence piece in the same project the previous articles using, FubuSample. I have also added all the code for this series to the FubuMVC-Contrib project

We will be implementing our persistence model to use NHibernate, Fluent NHibernate, Repository Pattern and UnitOfWork pattern all on top of SQL Express or standard. This will also work for sqllite and other database servers.

Class and Interfaces we have to implement:

• ISessionSourceConfiguration
• SQLServerSessionSourceConfiguration
• IUnitOfWork
• INHibernateUnitOfWork
• NHibernateUnitOfWork
• IRepository
• NHibernateRepository
• DomainEntity
• IDomainQuery
• FubuSamplePersistenceModel

Note: I put the first two in the list in my Core.Config namespace, and the rest in Core.Persistence

Before we start you probably want to go ahead and add the following references to your core project and Web project

Let’s just work our way down the list and get these files implemented.

ISessionSourceConfiguration

public interface ISessionSourceConfiguration

{

    bool IsNewDatabase { get; }

    ISessionSource CreateSessionSource(PersistenceModel model);

}

SQLServerSessionSourceConfiguration

public class SQLServerSessionSourceConfiguration : ISessionSourceConfiguration

{

    #region Implementation of ISessionSourceConfiguration

    public bool IsNewDatabase

    {

        get { return false; }

    }

    public ISessionSource CreateSessionSource(PersistenceModel model)

    {

        var properties = GetProperties();

        var source = new SessionSource(properties, model);

        create_schema_if_it_does_not_already_exist(source);

        return source;

    }

    private void create_schema_if_it_does_not_already_exist(ISessionSource source)

    {

        if (IsNewDatabase) source.BuildSchema();

    }

    protected IDictionary<string, string> GetProperties()

    {

        MsSqlConfiguration config = MsSqlConfiguration.MsSql2005;

        config.ConnectionString.FromConnectionStringWithKey(“MYDBKEY”);

        config.ShowSql();

        config.UseOuterJoin();

        return config.ToProperties();

    }

    #endregion

}

A quick note here: We told SQLServerSessionSourceConfiguration to use a connection string from the app settings file (Web.Config) with a key of “MYDBKEY” This will be important later.

IUnitOfWork

public interface IUnitOfWork : IDisposable

{

    void Initialize();

    void Commit();

    void Rollback();

}

INHibernateUnitOfWork

public interface INHibernateUnitOfWork : IUnitOfWork

{

    ISession CurrentSession { get; }

}

NHibernateUnitOfWork

public class NHibernateUnitOfWork : INHibernateUnitOfWork

{

    private ITransaction _transaction;

    private bool _isDisposed;

    private readonly ISessionSource _source;

    private bool _isInitialized;

    public NHibernateUnitOfWork(ISessionSource source)

    {

        _source = source;

    }

    public void Initialize()

    {

        should_not_currently_be_disposed();

        CurrentSession = _source.CreateSession();

        begin_new_transaction();

        _isInitialized = true;

    }

    public ISession CurrentSession { get; private set; }

    public void Commit()

    {

        should_not_currently_be_disposed();

        should_be_initialized_first();

        _transaction.Commit();

        begin_new_transaction();

    }

    private void begin_new_transaction()

    {

        if (_transaction != null)

        {

            _transaction.Dispose();

        }

        _transaction = CurrentSession.BeginTransaction();

    }

    public void Rollback()

    {

        should_not_currently_be_disposed();

        should_be_initialized_first();

        _transaction.Rollback();

        begin_new_transaction();

    }

    private void should_not_currently_be_disposed()

    {

        if (_isDisposed) throw new ObjectDisposedException(GetType().Name);

    }

    private void should_be_initialized_first()

    {

        if (!_isInitialized) throw new InvalidOperationException("Must initialize (call Initialize()) on NHibernateUnitOfWork before commiting or rolling back");

    }

    public void Dispose()

    {

        if (_isDisposed || !_isInitialized) return;

        _transaction.Dispose();

        CurrentSession.Dispose();

        _isDisposed = true;

    }

}

IRepository

public interface IRepository

{

    void Save<ENTITY>(ENTITY entity)

        where ENTITY : DomainEntity;

    ENTITY Load<ENTITY>(Guid id)

        where ENTITY : DomainEntity;

    IQueryable<ENTITY> Query<ENTITY>()

        where ENTITY : DomainEntity;

    IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery)

        where ENTITY : DomainEntity;

    void Delete<ENTITY>(ENTITY entity);

    void DeleteAll<ENTITY>();

}

NHibernateRepository

public class NHibernateRepository : IRepository

{

    private readonly INHibernateUnitOfWork _unitOfWork;

    public NHibernateRepository(INHibernateUnitOfWork unitOfWork)

    {

        _unitOfWork = unitOfWork;

    }

    public void Save<ENTITY>(ENTITY entity) where ENTITY : DomainEntity

    {

        _unitOfWork.CurrentSession.SaveOrUpdate(entity);

    }

    public ENTITY Load<ENTITY>(Guid id) where ENTITY : DomainEntity

    {

        return _unitOfWork.CurrentSession.Load<ENTITY>(id);

    }

    public IQueryable<ENTITY> Query<ENTITY>() where ENTITY : DomainEntity

    {

        return _unitOfWork.CurrentSession.Linq<ENTITY>();

    }

    public IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery) where ENTITY : DomainEntity

    {

        return _unitOfWork.CurrentSession.Linq<ENTITY>().Where(whereQuery.Expression);

    }

    public void Delete<ENTITY>(ENTITY entity)

    {

        _unitOfWork.CurrentSession.Delete(entity);   

    }

    public void DeleteAll<ENTITY>()

    {

        var query = String.Format("from {0}", typeof(ENTITY).Name);

        _unitOfWork.CurrentSession.Delete(query);   

    }

}

DomainEntity

Note: I put both of these classes in my Core.Domain namespace, also XML comments are in Source Repository

public class DomainEntity : IEquatable<DomainEntity>

{

    public virtual Guid ID { get; set; }

    public virtual bool Equals(DomainEntity other)

    {

        if (ReferenceEquals(null, other)) return false;

        if (ReferenceEquals(this, other)) return true;

        return other.ID.Equals(ID);

    }

    public override bool Equals(object obj)

    {

        if (ReferenceEquals(null, obj)) return false;

        if (ReferenceEquals(this, obj)) return true;

        if (obj.GetType() != GetType()) return false;

        return Equals((DomainEntity)obj);

    }

    public override int GetHashCode()

    {

        return ID.GetHashCode();

    }

    public static bool operator ==(DomainEntity left, DomainEntity right)

    {

        return Equals(left, right);

    }

    public static bool operator !=(DomainEntity left, DomainEntity right)

    {

        return !Equals(left, right);

    }

}

IDomainQuery

public interface IDomainQuery<ENTITY>

    where ENTITY : DomainEntity

{

    Expression<Func<ENTITY, bool>> Expression { get; }

}

FubuSamplePersistenceModel

namespace FubuSample.Core.Domain.Persistence

{

    public class FubuSamplePersistenceModel : PersistenceModel

    {

        public FubuSamplePersistenceModel()

        {

            addMappingsFromThisAssembly();

        }

    }

}

Now that we have all the puzzle pieces in place we need to hook them up and make them do some work. Open up FubuSampleWebRegistry

And add the following code:

protected override void configure()

{

    ForRequestedType<ISessionSourceConfiguration>().AsSingletons()

        .TheDefault.Is.OfConcreteType<SQLServerSessionSourceConfiguration>();

    ForRequestedType<ISessionSource>().AsSingletons()

        .TheDefault.Is.ConstructedBy(ctx =>

                                     ctx.GetInstance<ISessionSourceConfiguration>()

                                         .CreateSessionSource(new FubuSamplePersistenceModel()));

    ForRequestedType<IUnitOfWork>().TheDefault.Is.ConstructedBy(ctx => ctx.GetInstance<INHibernateUnitOfWork>());

    ForRequestedType<INHibernateUnitOfWork>().CacheBy(InstanceScope.Hybrid)

        .TheDefault.Is.OfConcreteType<NHibernateUnitOfWork>();

    ForRequestedType<IRepository>().TheDefault.Is.OfConcreteType<NHibernateRepository>();

}

With a little luck and all of our mad skills, we should be able to talk to the database now. So we need to plumb our simple product object up to talk to NHibernate. We will do this with a mapping file, and since we are using FluentNHibernate we can do this strongly typed.

Make the following modifications to Product: Extend DomainEntity and get rid of Id Property, it is inherited

public class Product : DomainEntity

{

    public virtual string Name { get; set; }

    public virtual string Description { get; set; }

}

Add mapping file for Product:

namespace FubuSample.Core.Domain.Mapping

{

    public class ProductMap : ClassMap<Product>

    {

        public ProductMap()

        {

            Id(e => e.ID).GeneratedBy.GuidComb();

            Map(p => p.Name);

            Map(p => p.Description);

        }

    }

}

You may also want to setup your connection string at this point in the Web.Config file, mine looks like this:

<add name="MYDBKEY" connectionString="Data Source=LOCALHOST;initial catalog=FubuSample;Integrated Security=SSPI;" providerName="System.Data.SqlClient" />

I also created an empty database in my local SQL Server instance called “FubuSample” And then I went back to SQLServerSessionSourceConfiguration and changed the value of IsNewDatabase to return true. This will create the schema for the database when the application first runs. There is a multitude of different ways that we can handle this, but this was easy for the tutorial purposes.

Next we will add a behavior to our core project and tell FubuMVC to apply that behavior to all or our ControllerActions.

Create a class named “access_the_database_through_a_unit_of_work” in your Core.Web.Behaviors namespace. The contents will look like this:

public class access_the_database_through_a_unit_of_work : IControllerActionBehavior

{

    private readonly IUnitOfWork _unitOfWork;

    public access_the_database_through_a_unit_of_work(IUnitOfWork unitOfWork)

    {

        _unitOfWork = unitOfWork;

    }

    public IControllerActionBehavior InsideBehavior { get; set; }

    public IInvocationResult Result { get; set; }

    public OUTPUT Invoke<INPUT, OUTPUT>(INPUT input, Func<INPUT, OUTPUT> func)

        where INPUT : class

        where OUTPUT : class

    {

        _unitOfWork.Initialize();

        try

        {

            var output = InsideBehavior.Invoke(input, func);

            Result = InsideBehavior.Result;

            _unitOfWork.Commit();

            return output;

        }

        catch

        {

            _unitOfWork.Rollback();

            throw;

        }

        finally

        {

            _unitOfWork.Dispose();

        }

    }

}

Now to tell FubuMVC what to do, open up Global.asax.cs or your Bootstrapper, wherever you are doing the configuration of FubuMVC. In this project we are doing it in Global.asax.cs Add a new behavior to the section that starts with “x.ByDefault.EveryControllerAction” so it looks like this:

x.ByDefault.EveryControllerAction(d =>

   {

       d.Will<execute_the_result>();

       d.Will<access_the_database_through_a_unit_of_work>();

   });

The last thing we will do is open up HomeController and add this code above the Index action:

private IRepository _repository;

public HomeController(IRepository repository)

{

    _repository = repository;

}

I also modified the Index action to go ahead and create some database values before we query for them just so we can test this thing. (I only did this for the tutorial, I swear) So modify the Index action to look like this:

public IndexViewModel Index(IndexSetupViewModel inModel)

{

    var prod1 = new Product {Name = "TestProduct1", Description = "This is a test product"};

    _repository.Save(prod1);

    var prod2 = new Product {Name = "TestProduct2", Description = "This is a test product"};

    _repository.Save(prod2);

    var outModel = new IndexViewModel();

    var productList = _repository.Query<Product>();

    outModel.Products = productList.ToList().Select(x => new ProductDisplay(x));

    return outModel;

}

Now with you should be able to run your web app and browse to /home and all this will be executed and you will be on your way to creating a whole bunch of persist able objects for use with your FubuMVC app.

As always, feedback is welcome.

Upcoming Topics:

Before You Begin

Project Setup

• FubuSample
  • lib
  • src
    • FubuSample.Core
    • FubuSample.Web
    • FubuSample.Tests
    • FubuSample.sln

1. 1. FubuSample.Core
      1. FubuMVC.Core
      2. FubuMVC.Container.StructureMap
      3. StructureMap
      4. Microsoft.Practices.ServiceLocation
   2. FubuSample.Web
      1. FubuSample.Core
      2. FubuMVC.Core
      3. FubuMVC.Container.StructureMap
      4. StructureMap
      5. Microsoft.Practices.ServiceLocation
   3. FubuSample.Tests
      1. FubuSample.Core
      2. FubuSample.Web
      3. FubuMVC.Core
      4. FubuMVC.Container.StructureMap
      5. NUnit.Framework
      6. Rhino.Mocks
      7. StructureMap

Luckily I found the JQuery DatePicker.  This used be a separate download, you can find the original here, but it is now part of JQuery.UI.

But first, there are a few tricks to using it (or any other JavaScript control for that matter).  First things first, this is not a separate server control that replaces the text box with a date friendly text box.  This is a javascript library that extends a standard text box and gives it date functionality.

So the first thing you have to do is put a text box on your form.

<asp:TextBox ID="DateTextBox" runat="server" />

Next on my list is to add the DatePicker JavaScript file, ui.datepicker.js.  I still use the Microsoft AJAX Library which has the nice ScriptManager control, so typically I use that control to add my JavaScript files to the page.

<link rel="stylesheet" href="~\Scripts\ui.datepicker.css" type="text/css" media="screen"  charset="utf-8" />

<asp:ScriptManagerProxy ID="ScriptManagerProxy1" runat="server">

    <Scripts>

        <asp:ScriptReference Path="~/Scripts/jquery.js" />

        <asp:ScriptReference Path="~/Scripts/ui.datepicker.js"  />

    </Scripts>

</asp:ScriptManagerProxy>

Note: I also included a link to the CSS file used to "skin" the calendar control.

Now everything is in place, we still  have to tell the javascript which text box control (DateTextBox) to put a Calendar control on.  I typically make a quick little JavaScript function that I can call to hook them up.  It looks like this:

function LoadDateControls() {

    $('#<%= DateTextBox.ClientID %>').attachDatepicker(); 

}

This code block asks the ASP.Net page for the ClientId of the text box control (very handy when dealing with Master Pages or User Control), and then attaches the date picker to the text box.

OK, the final bit of hooking up we have to do is call this function once the page is loaded and ready.  If we are using the Microsoft AJAX Library then you can use the pageLoad method like this:

function pageLoad(sender, args) {

    LoadDateControls();

}

If you want to stick with "pure" JQuery then you can do this instead:

$(document).ready(function() {

   LoadDateControls();

 });

Either way works, it is up to you which you like better.

So lets review where we are now.  We have added the JavaScript to our page, and pointed it at a text box to display a calendar.  If everything has gone according to plan, you should see something like what you see to the right when you click on the text box.

I like it.  And as far as I know all of the colors and fonts are configurable via css.

OK, that covers most of my requirements, but there was one other requirement that isn't here yet: Min and Max dates.

This one is a little harder.  First we have to know what Min and Max dates to use, and that will have to come from the code behind.  Assuming you know that, you can call this C# code:

protected string MinDate;

protected string MaxDate;

private void UpdateDateRangeContols(DateTime minDate, DateTime maxDate)

{

    MinDate = EncodeJsDate(minDate);

    MaxDate = EncodeJsDate(maxDate);

}

public string EncodeJsDate(DateTime date)

{

    return date.ToString("U") + " UTC";

}

Now I have a MinDate and MaxDate fields that I can access from my aspx page.  To do that I'm going to rewrite my LoadDateControls function to look like this:

function LoadDateControls() {

 <%

    Response.Write("$.datepicker.setDefaults({dateFormat:'m/d/yy', minDate: new Date('"+MinDate+"'), maxDate:new Date('"+MaxDate+"')});");

 %>

    $('#<%=DateTextBox.ClientID %>').attachDatepicker();

}

One side effect of that bit of code is that I also use it to specify the date format.

But wait, did I really just use a Response.Write in my ASP.Net file?  Isn't that old school and lame?  Old school: yes.  Lame: no (if used in moderation).  I'm note writing an entire web site using Response.Write, just setting some JavaScript.  Besides, if you want to be one of the cool kids and start using the MVC framework, you had better get used to Response.Write again.  You're going to need it.

In my code behind, I set my calendar controls to only allow date entries that go back 2 weeks.  Take a look at what we get.

Today's date is May 6 (highlighted in pink), so my date range is April 28 to May 11.  When you are on the month of May, the Next button is disabled.  And, if I hit the drop downs for Month I only see April and May, and for Year I only get 2008.  Same for April, I can't go to March.

OK, so what if all of this is too much for you.  This is too much code, to much work, all you want is darn server control to use.  You are in luck.  Head over to West Wind Technologies and pick up Rich Strahl's JQuery Calendar ASP.Net Control.  Also subscribe to his blog, he is usually worth the read.

Well, I had to revisit that idea today.  My problem wasn't with the Check All button that I made, that works fine, the problem was with the the check boxes in the grid view column themselves.  I was using the built in Asp.Net AJAX UpdatePanel to handle talking to the code behind EVERY time a check box what checked.

Worked fine on small grids with good connections.  But large grids with bad connections...not so much.  The problem was that the entire grid was being reloaded with every check box click.  Not good.  If you want to see more reasons on why to beware UpdatePanel see Encosia's "Why ASP.Net AJAX UpdatePanels are Dangerous".

My solution was to replace the call-back/post-back with a JavaScript function and a WebService call.  Now, I have a web service class called (wait for it): WebService.asmx.  I'm going to use the ScriptManager to help me with this, by adding my WebService class to the ScriptManager's Services node.

<asp:ScriptManager ID="ScriptManager1" runat="server">

   <Services>

       <asp:ServiceReference Path="WebService.asmx" />

   </Services>

</asp:ScriptManager>

This tells the ScriptManager to generate some JavaScript wrappers that will make calling my web service call easier.  Bonus, I have my script manager in my Master Page, so now I can call this web service class from any content page.  Otherwise, I could change ScriptManager to ScriptManagerProxy and do the same thing on specific pages.

So, I have to add a web service method to my WebService class that I can call from JavaScript.  Here you go:

[WebMethod][ScriptMethod]

public void Reviewed(string userName, bool reviewed)

{

    // calls my database wrapper class that executes the sql command.

    // but I don't want to get into that right now, just go look up LINQ to SQL

    // or NHibernate, or SubSonic, or ...

    _dbo.Reviewed(userName, reviewed);

}

OK, that is the first easy part.  I now have a web service that I can call from my JavaScript.  Let's move onto the next easy part.  Hooking up a CheckBox control to execute the web service.

First thing I'm going to do is create a small JavaScript function on the page that actually calls the web service method.  I'll call it Reviewed:

<script type="text/javascript">

    function Reviewed(ctrl, UserName) {

        var isCheck = ctrl.checked;

        WebService.Reviewed(UserName,isCheck);

    }

</script>

Next comes up hooking up the CheckBox.  Now, if all I had to do was set the onclick property to call the function, it would be easy.  The code would look like this:

<asp:CheckBox ID="ReviewedCheckBox"  CssClass="ApprovalCheckBox" runat="server" onclick='CallJavacriptfunction(this)' />

But I need more data than that.  I also need to username.  Plus, this is in a GridView.  So I actually have to catch the OnRowDataBound event, and set the attribute programmatically.

protected void gvTimecard_RowDataBound(Object sender, GridViewRowEventArgs e)

{

    if (e.Row.RowType == DataControlRowType.DataRow)

    {

        string clickEventText = "Reviewed(this, \"{0}\");";

        string currentUser = HttpContext.Current.User.Identity.Name;

        clickEventText = string.Format(clickEventText, currentUser );

        CheckBox cb = (CheckBox)e.Row.FindControl("ReviewedCheckBox");

        cb.Attributes["onclick"] = clickEventText;

    }

}

And that is really about it.  This will now call the web service from the check box, using JavaScript, but without any post backs at all.  As a bonus, I'm passing around just the data that I need to execute the function.  No ViewState, no reloading the entire grid. 

Much, much, much better.

First Task: MembershipProvider.CreateUser

There is some logic involved in maintaining the in-memory information, and I certainly don't want to have to run a web application to test the functionality as I'm building it, so the first thing is to create a ".Test" assembly. 

My first test for creating a MembershipUser looked something like this:

[Test]
public void CreateUser()
{
    // this is what we're testing:
    var provider = new VirtualMembershipProvider();
    
    // creation of all of these args omitted for brevity..
    var user = provider.CreateUser(...);
    
    // verify that the MembershipUser is valid..
    Assert.AreEqual(user.UserName, userName); // etc.etc.etc.
}

And the implementation of VirtualMembershipProvider.CreateUser():  (obviously I'm leaving out some unimportant details..)

public override MembershipUser CreateUser(...)
{
    // MembershipUser takes crazy big number of args..
    MembershipUser user = new MembershipUser(...);
    // TODO: put that user object somewhere for later access..
    status = MembershipCreateStatus.Success;
    return user;
}

Can't get much simpler, right? 

First Issue - Arbitrary Dependency

Running the test gives an exception from the MembershipUser constructor: "System.ArgumentException : The membership provider name specified is invalid." So, we jump over to Reflector to see what's going on:

if ((providerName == null) || 
    (Membership.Providers[providerName] == null))
{
  throw new ArgumentException(...);
}

MembershipUser has a dependency on Membership.Providers.  This is because MembershipUser is not just a data container, but breaks the Single Responsibility Principle (SRP) and has methods like Update() as well.  But, whatever.  Looks like all I've got to do is add my VirtualMembershipProvider into that Membership.Providers collection, and we'll be set.

Next Issue - Arbitrary ReadOnly-ness

I put "Membership.Providers.Add()" into the test, to see what happens.  Running the test gives me a new exception: in ProviderCollection.Add() - "System.NotSupportedException : Collection is read-only."  Argh!  Back to Reflector!  Here's what ProviderCollection.Add() looks like (more or less):

public virtual void Add(ProviderBase provider)
{
    if (this._ReadOnly)
        throw new NotSupportedException(...);
    // some other guard clauses...
    this._Hashtable.Add(provider.Name, provider);
}

So all I've got to do is call ".IsReadOnly = false" and... ha ha jokes on me.  ProviderCollection has a SetReadOnly() method, but no public way to switch readonly-ness off.  Presumably there's some really good reason for making things difficult with this totally artificial wall that they put in our path.

So, we fall back to the tool of last resort: reflection to get that private _ReadOnly field and set it to false.  Now we can register our provider into the ProviderCollection.  But, what an ugly hack, for seemingly no reason.

One more thing lacking: before the ProviderCollection will accept a Provider, it checks to see if the Provider has been initialized properly.  So we need a call to provider.Initialize() which sets some internal state on the provider.

(Note: by this point, we actually have a fair amount of initialization code here, and its getting complicated.  So this code was moved into its own class & tests - I've left that part out to be more concise.)

More or less, we've got this code to set up our MembershipProvider, outside of the official procedures:

public static void Initialize(MembershipProvider provider, 
                              string providerName)
{
    provider.Initialize(providerName, null);
    // grabs a cached FieldInfo instance and sets it appropriately.
    // note this would affect all Membershp providers...
    AllowNewProviders = true;
    Membership.Providers.Add(provider);
}

And now, our CreateUser() test passes and we can get back to work on the REAL problem. 

Conclusions

• Don't put arbitrary roadblocks in your framework.  You have no idea how somebody will need to use (and abuse) it.
• Strive to keep your code decoupled.  Always a good idea no matter what you're working on.
• This is "running with scissors:" I wouldn't propose subverting the Provider model with this sort of hackery for code that you wanted to use in production, at least not with much more testing and consideration.  There might be (and probably is) a really good reason for that _ReadOnly flag, and we just broke it..
• And to bring us back to the first point: framework developers should provide the "default safe" implementation with that _ReadOnly flag, but then at least provide a way to cleanly get around the safety mechanism, for those of us who are willing to accept the risk.

So, ASP.NET, thanks for the offer of holding my hand through every step of the way, but instead how about you just get out of my way and let me get my work done, kthxbai.

Good thing MS has exposed a set of interfaces and abstract classes in System.Web.UI for us to implement our own IHierarchicalDataSource and HierarchicalDataSourceView and IHierarchicalEnumerable and then IHierarchyData... geesh.

Data? So let's see here, in order to bind our model to the tree control it needs to implement an interface in System.Web.UI? Well that's just not going to happen, so its time for some Elegant Code.

Story:

Dude, as a software developer, needs to create a custom implementation of IHierarchicalDataSource, and the rest of its parts, so that he can bind a list of objects to a tree control in asp.net

• Use existing model to bind to tree control
• Must be able to reuse data source for future models
• Model must not contain a reference to System.Web.UI

In order to setup our model to address the acceptance criteria we are going to use an interface with a self-referencing generic declaration, where the type will specify itself as the concrete type. This will let us create a nice generic hierarchical model to pass into our datasource without resorting to any sort of base class.

namespace POC.Common
{
    public interface IModelWithHierarchy<T>
    {
        string Name { get; set; }
        T Parent { get; set; }
        List<T> Children { get; set; }
    }
}

The UI part of criteria is now a bit more tricky because the HierarchicalDataSourceView expects a IHierarchicalEnumerable datasource which contains IHierarchyData. Said IHierarchyData != IModelWithHierarchy<T>.  Luckily someone else has already figured this one out for us. We need an adapter.

To instantiate our HierarchyData adapter objects we will use an extension method and linq 'Select' to convert our datasource IEnumerable<T> of IModelWithHierarchy<T> 's to an IHierarchicalEnumerable of IHierarchyData.

namespace POC.Web.HierarchyExtensions
{
    public static class HierarchyConverter
    {
        public static HierarchicalModelList
            ToHierarchicalModelList<T>(this IEnumerable<T> modelWithHierarchy)
            where T : IModelWithHierarchy<T>
        {
            return new HierarchicalModelList(
                modelWithHierarchy.Select(m => new HierarchyData<T>(m) as IHierarchyData));
        }
    }
}

I am not going to bore you with the implementation details of the HierarachyData<T> adapter and the .net abstractions, but have dropped the source code here if your interested. The end result:

TreeView1.DataSource = new HierarchicalModelDataSource<Category> { DataSource = Categories };
TreeView1.DataBind();
TreeView1.CollapseAll();

Story complete! 

I am sure everyone will be blogging about all the great sessions they attended at code camp. I enjoyed all of the presentations I attended, and I am excited to explore some new material.

I want to share a few thoughts on my presentation dealing with Model-View-Presenter in ASP.NET after listening to Scott Hanselman's session on the ASP.NET MVC Project. I may have the percentage incorrect, but Scott mentioned something like it is predicted that only 10% of the ASP.NET community currently using Web Forms will adopt and use the MVC framework. The MVC framework is an addition to ASP.NET, it is not a replacement. What this means is that Model-View-Presenter will still be a viable pattern to implement with your ASP.NET applications, and it is not going away. ASP.NET Web Forms will not be going away either.

Use MVP to get your third party controls under test. Use MVP to provide that separation of concerns in your legacy applications. Use it entirely or in conjunction with the MVC framework. It is all about testability. Glenn Block presented on the Web Client Software Factory, and what pattern does this implement? Model-View-Presenter.

I am providing my presentation and source code (3.67 MB) from my talk on MVP. It will be available via the Boise Code Camp site as well.

Again, thank the many individuals and their families who sacrificed their time to bring to the local community this years code camp.

Around the office's water cooler on Monday, I will be able to say, "and this one time, at code camp..."

For the most part the Bundle rocks, but there are a few things which didn't meet our needs:

1. The default PropertyProxyValidator inherits from System.Web.UI.WebControls.BaseValidator, like the other Asp.Net validators. This makes it great for mixing all types of standard Validators (Like Regex or RequiredField), but has a major drawback for Client side validation because it validates on every PostBack (full) as well as Callback (partial).
2. On a full postback, such as a form submit, the ServerSideValidationExtender issues a Callback request to the Validator
3. Even if the value had not changed, validation still occurs.

A simple scenario

We have an Organization with two fields, Name & Code

Lets look at the validation events:

• Enter Name 'Bob's Plumbing', Press Tab (or click off)
  • Callback: Validation occurs for Name
• Enter Code 'BPL', Press Tab (or click off)
  • Callback: Validation occurs for Code
• Click Save
  • Callback: Validation occurs for Name
  • Callback: Validation occurs for Code
  • Postback (full): Validation Occurs for Name & Code

So we have validated each property 3 times. This might be OK we were just parsing for special characters, but in our case we also want to call a service and see if these values already exist in our system: 3x is too expensive.

Aside from being expensive, this is a unique type of validation where we want to check if a condition isn't true (Org Name doesn't exist) vs. is true. (an valid email address or a valid state)

This makes point #3 above especially troubling for our scenario, because if we want to edit this Organization in the future, any time we change a value, all the rest of the validators will fire and come back invalid as they already exist.

Example updating just the Org Code, which causes the Name to validate:

The Solution

• Kill the full postback validation with OnCallBackPropertyProxyValidator
• Modify ServerSideValidationExtender to *only* validate if the value has changed

OnCallBackPropertyProxyValidator

OnCallBackPropertyProxyValidator is a pretty quick fix. We will just inherit the ProperyProxyValidator and kick out of the EvaluateIsValid method if its not a CallBack.

   1:    /// <summary>

   2:    /// Class which only performs validation when page is in a callback state

   3:    /// </summary>

   4:    public class OnCallBackPropertyProxyValidator : PropertyProxyValidator

   5:    {

   6:        /// <summary>

   7:        /// If Page.IsCallBack, determines whether the content in the input control is valid.

   8:        /// </summary>

   9:        /// <returns><see langword="true"/> if the control is valid; otherwise, <see langword="false"/>.</returns>

  10:        protected override bool EvaluateIsValid()

  11:        {

  12:            if (!this.Page.IsCallback)

  13:            {

  14:                this.ErrorMessage = "";

  15:                return true;

  16:            }

  17:            else 

  18:            {

  19:                return base.EvaluateIsValid();

  20:            }

  21:        }

  22:    }

ServerSideValidation

Well add the 'only-validate-if-value-changed' functionality by fetching the current text value from the control to be validated, storing the property in JSON, and then evaluating if the value has changed before requesting validation from the server.

Modifying the ServerSideValidationExtender.cs

Add the CurrentValue Property to the Extender C# class:

   1: [ExtenderControlProperty]

   2: [ClientPropertyName("currentValue")]

   3: [DefaultValue("")]

   4: public string CurrentValue

   5: {

   6:     get { return GetPropertyValue<string>("CurrentValue", string.Empty); }

   7:     set { SetPropertyValue<string>("CurrentValue", value); }

   8: }

Set the current value in OnPreRender:

   1: protected override void OnPreRender(EventArgs e)

   2:     {

   3:         base.OnPreRender(e);

   4:        

   5:         Omitted code here....        

   6:  

   7:         // Set the current Text value

   8:         Control controlToValidate = extendedValidator.NamingContainer.FindControl(extendedValidator.ControlToValidate);

   9:         ITextControl textControl = controlToValidate as ITextControl;

  10:         if (textControl != null)

  11:         {

  12:             CurrentValue = textControl.Text;

  13:         }

  14:         

  15:         Omitted code here...

  16:     }

Modifying the ServerSideValidationBehavior.js Behavior

Add the CurrentValue property to the descriptor:

   1: AjaxControlToolkit.WCSFExtensions.ServerSideValidationBehavior.descriptor = {

   2:    properties: [   {name: 'callbackControl', type: String},

   3:                    {name: 'validateEmptyText', type: Boolean},

   4:                    {name: 'currentValue', type: String} ]

   5: }

Add the accessor methods to the prototype:

   1: get_currentValue: function(){

   2:     return this.currentValue;

   3: },

   4: set_currentValue: function(value){

   5:     this.currentValue = value;

   6: }

And finally check to see if the value has changed

   1: Validate: function() {

   2:     var valueToValidate = this._getValueToValidate();

   3:  

   4:     Omitted....

   5:  

   6:     if (valueToValidate === this.get_currentValue()) {

   7:         return true;

   8:     }

   9:     

  10:     Omitted.... 

  11:     

  12: },

And that's it. What we end up with is client side validation which only occurs when the value is changed on the client, through a callback, and no where else. All other validation works in tandem as expected, such as the standard ASP.NET validators, PropertyProxyValidator, or a custom validator which performs VAB self validation.

Though the Bundle didn't do everything we were looking for right out of the box, it was pretty easy to get in there and make work exactly how we wanted. Hats off to P&P for some great guidance.

The source code is here. Its just the files, not a complete working solution, but if you download the WCSF source/ Validation Bundle you should be able to plug it in fairly easily.

Secondly, I am very involved in our local Code Camp and I can tell you that finding a web portal to use out of the box has been nigh on impossible. I strongly considered starting a project exactly like this one because I didn't want to be caught in the lurch next year.

Now I can thank Jeffery Palermo for beating me to the punch.

I look forward to using this next year for our Boise Code Camp.

• FubuMVC From Scratch Part 1 – Basic project structure setup
• FubuMVC From Scratch Part 2 – FubuMVC configuration and Controller setup
• FubuMVC From Scratch – Part 3 (Adding View to project)

Persistence is a requirement in virtually every application that we write today, and now the time has come for us to add a persistence model to our FubuMVC app. I know I mentioned moving my samples to the FubuCart source, but I am going to go ahead and implement the persistence piece in the same project the previous articles using, FubuSample. I have also added all the code for this series to the FubuMVC-Contrib project

We will be implementing our persistence model to use NHibernate, Fluent NHibernate, Repository Pattern and UnitOfWork pattern all on top of SQL Express or standard. This will also work for sqllite and other database servers.

Class and Interfaces we have to implement:

• ISessionSourceConfiguration
• SQLServerSessionSourceConfiguration
• IUnitOfWork
• INHibernateUnitOfWork
• NHibernateUnitOfWork
• IRepository
• NHibernateRepository
• DomainEntity
• IDomainQuery
• FubuSamplePersistenceModel

Note: I put the first two in the list in my Core.Config namespace, and the rest in Core.Persistence

Before we start you probably want to go ahead and add the following references to your core project and Web project

Let’s just work our way down the list and get these files implemented.

ISessionSourceConfiguration

public interface ISessionSourceConfiguration

{

    bool IsNewDatabase { get; }

    ISessionSource CreateSessionSource(PersistenceModel model);

}

SQLServerSessionSourceConfiguration

public class SQLServerSessionSourceConfiguration : ISessionSourceConfiguration

{

    #region Implementation of ISessionSourceConfiguration

    public bool IsNewDatabase

    {

        get { return false; }

    }

    public ISessionSource CreateSessionSource(PersistenceModel model)

    {

        var properties = GetProperties();

        var source = new SessionSource(properties, model);

        create_schema_if_it_does_not_already_exist(source);

        return source;

    }

    private void create_schema_if_it_does_not_already_exist(ISessionSource source)

    {

        if (IsNewDatabase) source.BuildSchema();

    }

    protected IDictionary<string, string> GetProperties()

    {

        MsSqlConfiguration config = MsSqlConfiguration.MsSql2005;

        config.ConnectionString.FromConnectionStringWithKey(“MYDBKEY”);

        config.ShowSql();

        config.UseOuterJoin();

        return config.ToProperties();

    }

    #endregion

}

A quick note here: We told SQLServerSessionSourceConfiguration to use a connection string from the app settings file (Web.Config) with a key of “MYDBKEY” This will be important later.

IUnitOfWork

public interface IUnitOfWork : IDisposable

{

    void Initialize();

    void Commit();

    void Rollback();

}

INHibernateUnitOfWork

public interface INHibernateUnitOfWork : IUnitOfWork

{

    ISession CurrentSession { get; }

}

NHibernateUnitOfWork

public class NHibernateUnitOfWork : INHibernateUnitOfWork

{

    private ITransaction _transaction;

    private bool _isDisposed;

    private readonly ISessionSource _source;

    private bool _isInitialized;

    public NHibernateUnitOfWork(ISessionSource source)

    {

        _source = source;

    }

    public void Initialize()

    {

        should_not_currently_be_disposed();

        CurrentSession = _source.CreateSession();

        begin_new_transaction();

        _isInitialized = true;

    }

    public ISession CurrentSession { get; private set; }

    public void Commit()

    {

        should_not_currently_be_disposed();

        should_be_initialized_first();

        _transaction.Commit();

        begin_new_transaction();

    }

    private void begin_new_transaction()

    {

        if (_transaction != null)

        {

            _transaction.Dispose();

        }

        _transaction = CurrentSession.BeginTransaction();

    }

    public void Rollback()

    {

        should_not_currently_be_disposed();

        should_be_initialized_first();

        _transaction.Rollback();

        begin_new_transaction();

    }

    private void should_not_currently_be_disposed()

    {

        if (_isDisposed) throw new ObjectDisposedException(GetType().Name);

    }

    private void should_be_initialized_first()

    {

        if (!_isInitialized) throw new InvalidOperationException("Must initialize (call Initialize()) on NHibernateUnitOfWork before commiting or rolling back");

    }

    public void Dispose()

    {

        if (_isDisposed || !_isInitialized) return;

        _transaction.Dispose();

        CurrentSession.Dispose();

        _isDisposed = true;

    }

}

IRepository

public interface IRepository

{

    void Save<ENTITY>(ENTITY entity)

        where ENTITY : DomainEntity;

    ENTITY Load<ENTITY>(Guid id)

        where ENTITY : DomainEntity;

    IQueryable<ENTITY> Query<ENTITY>()

        where ENTITY : DomainEntity;

    IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery)

        where ENTITY : DomainEntity;

    void Delete<ENTITY>(ENTITY entity);

    void DeleteAll<ENTITY>();

}

NHibernateRepository

public class NHibernateRepository : IRepository

{

    private readonly INHibernateUnitOfWork _unitOfWork;

    public NHibernateRepository(INHibernateUnitOfWork unitOfWork)

    {

        _unitOfWork = unitOfWork;

    }

    public void Save<ENTITY>(ENTITY entity) where ENTITY : DomainEntity

    {

        _unitOfWork.CurrentSession.SaveOrUpdate(entity);

    }

    public ENTITY Load<ENTITY>(Guid id) where ENTITY : DomainEntity

    {

        return _unitOfWork.CurrentSession.Load<ENTITY>(id);

    }

    public IQueryable<ENTITY> Query<ENTITY>() where ENTITY : DomainEntity

    {

        return _unitOfWork.CurrentSession.Linq<ENTITY>();

    }

    public IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery) where ENTITY : DomainEntity

    {

        return _unitOfWork.CurrentSession.Linq<ENTITY>().Where(whereQuery.Expression);

    }

    public void Delete<ENTITY>(ENTITY entity)

    {

        _unitOfWork.CurrentSession.Delete(entity);   

    }

    public void DeleteAll<ENTITY>()

    {

        var query = String.Format("from {0}", typeof(ENTITY).Name);

        _unitOfWork.CurrentSession.Delete(query);   

    }

}

DomainEntity

Note: I put both of these classes in my Core.Domain namespace, also XML comments are in Source Repository

public class DomainEntity : IEquatable<DomainEntity>

{

    public virtual Guid ID { get; set; }

    public virtual bool Equals(DomainEntity other)

    {

        if (ReferenceEquals(null, other)) return false;

        if (ReferenceEquals(this, other)) return true;

        return other.ID.Equals(ID);

    }

    public override bool Equals(object obj)

    {

        if (ReferenceEquals(null, obj)) return false;

        if (ReferenceEquals(this, obj)) return true;

        if (obj.GetType() != GetType()) return false;

        return Equals((DomainEntity)obj);

    }

    public override int GetHashCode()

    {

        return ID.GetHashCode();

    }

    public static bool operator ==(DomainEntity left, DomainEntity right)

    {

        return Equals(left, right);

    }

    public static bool operator !=(DomainEntity left, DomainEntity right)

    {

        return !Equals(left, right);

    }

}

IDomainQuery

public interface IDomainQuery<ENTITY>

    where ENTITY : DomainEntity

{

    Expression<Func<ENTITY, bool>> Expression { get; }

}

FubuSamplePersistenceModel

namespace FubuSample.Core.Domain.Persistence

{

    public class FubuSamplePersistenceModel : PersistenceModel

    {

        public FubuSamplePersistenceModel()

        {

            addMappingsFromThisAssembly();

        }

    }

}

Now that we have all the puzzle pieces in place we need to hook them up and make them do some work. Open up FubuSampleWebRegistry

And add the following code:

protected override void configure()

{

    ForRequestedType<ISessionSourceConfiguration>().AsSingletons()

        .TheDefault.Is.OfConcreteType<SQLServerSessionSourceConfiguration>();

    ForRequestedType<ISessionSource>().AsSingletons()

        .TheDefault.Is.ConstructedBy(ctx =>

                                     ctx.GetInstance<ISessionSourceConfiguration>()

                                         .CreateSessionSource(new FubuSamplePersistenceModel()));

    ForRequestedType<IUnitOfWork>().TheDefault.Is.ConstructedBy(ctx => ctx.GetInstance<INHibernateUnitOfWork>());

    ForRequestedType<INHibernateUnitOfWork>().CacheBy(InstanceScope.Hybrid)

        .TheDefault.Is.OfConcreteType<NHibernateUnitOfWork>();

    ForRequestedType<IRepository>().TheDefault.Is.OfConcreteType<NHibernateRepository>();

}

With a little luck and all of our mad skills, we should be able to talk to the database now. So we need to plumb our simple product object up to talk to NHibernate. We will do this with a mapping file, and since we are using FluentNHibernate we can do this strongly typed.

Make the following modifications to Product: Extend DomainEntity and get rid of Id Property, it is inherited

public class Product : DomainEntity

{

    public virtual string Name { get; set; }

    public virtual string Description { get; set; }

}

Add mapping file for Product:

namespace FubuSample.Core.Domain.Mapping

{

    public class ProductMap : ClassMap<Product>

    {

        public ProductMap()

        {

            Id(e => e.ID).GeneratedBy.GuidComb();

            Map(p => p.Name);

            Map(p => p.Description);

        }

    }

}

You may also want to setup your connection string at this point in the Web.Config file, mine looks like this:

<add name="MYDBKEY" connectionString="Data Source=LOCALHOST;initial catalog=FubuSample;Integrated Security=SSPI;" providerName="System.Data.SqlClient" />

I also created an empty database in my local SQL Server instance called “FubuSample” And then I went back to SQLServerSessionSourceConfiguration and changed the value of IsNewDatabase to return true. This will create the schema for the database when the application first runs. There is a multitude of different ways that we can handle this, but this was easy for the tutorial purposes.

Next we will add a behavior to our core project and tell FubuMVC to apply that behavior to all or our ControllerActions.

Create a class named “access_the_database_through_a_unit_of_work” in your Core.Web.Behaviors namespace. The contents will look like this:

public class access_the_database_through_a_unit_of_work : IControllerActionBehavior

{

    private readonly IUnitOfWork _unitOfWork;

    public access_the_database_through_a_unit_of_work(IUnitOfWork unitOfWork)

    {

        _unitOfWork = unitOfWork;

    }

    public IControllerActionBehavior InsideBehavior { get; set; }

    public IInvocationResult Result { get; set; }

    public OUTPUT Invoke<INPUT, OUTPUT>(INPUT input, Func<INPUT, OUTPUT> func)

        where INPUT : class

        where OUTPUT : class

    {

        _unitOfWork.Initialize();

        try

        {

            var output = InsideBehavior.Invoke(input, func);

            Result = InsideBehavior.Result;

            _unitOfWork.Commit();

            return output;

        }

        catch

        {

            _unitOfWork.Rollback();

            throw;

        }

        finally

        {

            _unitOfWork.Dispose();

        }

    }

}

Now to tell FubuMVC what to do, open up Global.asax.cs or your Bootstrapper, wherever you are doing the configuration of FubuMVC. In this project we are doing it in Global.asax.cs Add a new behavior to the section that starts with “x.ByDefault.EveryControllerAction” so it looks like this:

x.ByDefault.EveryControllerAction(d =>

   {

       d.Will<execute_the_result>();

       d.Will<access_the_database_through_a_unit_of_work>();

   });

The last thing we will do is open up HomeController and add this code above the Index action:

private IRepository _repository;

public HomeController(IRepository repository)

{

    _repository = repository;

}

I also modified the Index action to go ahead and create some database values before we query for them just so we can test this thing. (I only did this for the tutorial, I swear) So modify the Index action to look like this:

public IndexViewModel Index(IndexSetupViewModel inModel)

{

    var prod1 = new Product {Name = "TestProduct1", Description = "This is a test product"};

    _repository.Save(prod1);

    var prod2 = new Product {Name = "TestProduct2", Description = "This is a test product"};

    _repository.Save(prod2);

    var outModel = new IndexViewModel();

    var productList = _repository.Query<Product>();

    outModel.Products = productList.ToList().Select(x => new ProductDisplay(x));

    return outModel;

}

Now with you should be able to run your web app and browse to /home and all this will be executed and you will be on your way to creating a whole bunch of persist able objects for use with your FubuMVC app.

As always, feedback is welcome.