The next Brighton ALT.NET Beers will be held at the co-working venue ‘The Skiff’ at 7.00 pm on Tuesday 4th May. I’ll be hosting again.
The address is: The Skiff, 49 Cheltenham Place, Brighton, BN1 4AB
The format will be the same as usual, a quick round of suggestions for topics, voting and then an evening of beer and geekery.
See you there!
There’s a lot of confusion over these two terms. By myself included. But I’m pretty happy now that I understand the difference and wanted to share my newfound knowledge with you, dear reader.
First let’s understand the arrow (->), it’ll make the discussion much easier. This operator (->) is used in F#, Haskell and other functional programming languages to define function types. If you’ve got an ‘add’ function that takes two int arguments and returns an int, you would write that function’s type like this (in F#):
int * int –> int
Which says, the function takes a tuple of two int values and returns an int. Remember F# functions only ever have one argument and one return value. Now take a look at this type:
int –> int –> int
This function takes an int value and returns a function. The function it returns takes an int value and returns an int value. Turning the first example into the second example is ‘currying’. So currying is the process of taking a function with multiple arguments and turning it into a function that takes only one argument and returns a new function that takes the second argument and returns a value (or a further function which takes the third argument and returns a value or…. you get the picture).
Partial application is when you actually use a such a curried function. So in our add example above, if we have defined a curried add (in F#) as:
> let add a b = a + b;; val add : int -> int -> int
Isn’t that neat, we don’t actually need to ‘curry’ add, F# provides curried functions by default. Now we use the add function like this:
> let add5 = add 5;; val add5 : (int -> int)
F# is now telling us that add5 is a function that takes an int and returns an int. We’ve partially applied add. Now we can use add5 like any other function:
> add5 2;; val it : int = 7 > add5 7;; val it : int = 12
Having curried functions by default is very cool indeed. It means we can use partial application to compose functions in the same way that we use dependency injection to compose classes in object-oriented languages.
Here’s some interesting NHibernate behaviour that’s been tripping me up. Say we have a base class ‘Content’ and a sub class ‘Menu’, the following tests pass:
[Test] public void Get_returns_a_proxy_of_the_correct_type() { InSession(session => { var content = session.Get<Content>(menu1Id); var menu = content as Menu; menu.ShouldNotBeNull("menu is null"); }); } [Test] public void Load_does_not_get_return_a_proxy_of_the_correct_type() { InSession(session => { var content = session.Load<Content>(menu1Id); var menu = content as Menu; menu.ShouldBeNull(); }); }
That’s right, don’t expect ‘as’ to work on lazily loaded entities.
Get eagerly loads, so it runs some SQL against the database:
SELECT content0_.ContentId as ContentId15_0_, content0_.Name as Name15_0_, content0_.Position as Position15_0_, content0_.IsActive as IsActive15_0_, content0_.UrlName as UrlName15_0_, content0_.ParentContentId as ParentCo7_15_0_, content0_.ContentTypeId as ContentT8_15_0_, content0_.Controller as Controller15_0_, content0_.Action as Action15_0_, content0_.Text as Text15_0_, content0_.ContentType as ContentT2_15_0_ FROM "Content" content0_ WHERE content0_.ContentId=@p0;@p0 = 1 [Type: Int32 (0)]
This includes the discriminator column, ContentType, so NHibernate knows that this item should be created as a menu.
Load, lazy loads, so for this example no SQL is run against the database. The only thing NHibernate knows about this entity is that we’ve asked for ‘Content’ via the type parameter of the Load method, so it returns a proxy class that inherits from Content. When we use the ‘as’ operator to cast it to a menu it fails (returns null).
Interestingly, the type is still incorrect after we examine some properties so that the proxy is populated with a call to the db:
[Test] public void Type_is_not_correct_after_the_entity_loaded() { InSession(session => { var content = session.Load<Content>(menu1Id); Console.WriteLine(content.Name); var menu = content as Menu; menu.ShouldBeNull(); }); }
Event though this test causes the select statement to be executed against the DB to populate the entity, the proxy is still of type Content.
So rather than using the ‘as’ operator, I’ve implemented my own CastAs<T> extension method that understands NHibernate proxies:
public static class CastExtensions { public static T CastAs<T>(this object source) where T : class { if(source is INHibernateProxy) { var type = NHibernateUtil.GetClass(source); if (type != typeof (T)) { throw new ApplicationException(string.Format("Cannot cast {0} to {1}", type.Name, typeof (T).Name)); } return ((INHibernateProxy) source).HibernateLazyInitializer.GetImplementation() as T; } return source as T; } }
Now the we get the correct sub type:
[Test] public void Use_CastAs_to_cast_lazy_loaded_entities() { InSession(session => { var content = session.Load<Content>(menu1Id); Console.WriteLine(content.GetType().Name); var menu = content.CastAs<Menu>(); menu.ShouldNotBeNull(); }); }
Update
As Mookid pointed out in the comments, doing this kind of casting, especially of domain classes, is a code smell. What I should be doing instead is using polymorphism or the visitor pattern. Please read his post below which is a very cool alternative take on the problem:
I’ve finished getting the basic features of Suteki Shop running with NHibernate. Anyone who’s been following this project knows that it was originally written with Linq-to-SQL. Linq-to-SQL worked fine for the initial iterations of Suteki Shop, but there are lots of things I wanted to do with the project that would have been hard or impossible to do without the move.
Linq-to-SQL not a true ORM in the sense that it doesn’t support persistence ignorance, it’s more a object based projection of a relational database. Each class directly represents a table row, including foreign keys. One of the main pain points in the transition was removing all the application code that referenced these foreign keys and replacing them with object references instead. So for example, instead of changing the int value of Contact.CountryId I would change the actual referenced entity, Contact.Country.
The other place where I had to do lots of work was in my Linq queries. The NHibernate trunk now has a native Linq provider written by Steve Strong, so you can write:
var customer = session.Query<Customer>().Where(c => c.Name == "Fred").FirstOrDefault();
The main difference between the Linq-to-SQL provider and the NHiberante one is in the way they treat expressions that they don’t understand. Linq-to-SQL will translate as much of the expression that it can to SQL, get the result, and then allow Linq-to-objects to do the rest. The NHibernate provider will throw an exception saying that it doesn’t understand the expression. There are pros and cons to both approaches. Linq-to-SQL will always give you what you want, but maybe in an inefficient way you weren’t expecting, whereas NHibernate will force you to think about how you structure your queries. There are no surprises, but it’s a mark against persistence ignorance. Right now, I’m liking the NHibernate no surprises approach.
Whilst doing the conversion I ran into a problem with the OfType<T>() Linq extension method. I was using it in several places but NHibernate complained that it didn’t support it. I tweeted about it and almost immediately Steve Strong replied that it should be easy to implement. The next day he committed it to the NHibernate trunk and my queries all worked.
Steve Strong, you are an awesome open source hero!
One of my major regrets with the way that I originally wrote Suteki Shop is binding views to entities, rather than using a view model. At first this can seem like an easy-win, but doing this work showed how can soon lead to all sorts of difficulties. Displaying the view model in the view is not so much of a problem - except in entity loading overhead. The problems mostly manifest themselves at the binding stage. I extended the ASP.NET MVC DefaultModelBinder to work with NHibernate entities, and it mostly works, but I spent far too much time resolving tricky binding issues with complex object graphs. I would have made my life much easier by binding to a nice flat view model and then manually mapping that to my entities.
Persistence ignorance is a dream, a nirvana, where we’d love to be, but no ORM will give you true persistence ignorance. NHibernate is far better in this regard than Linq-to-SQL, but you still have to do things the NHibernate way. Your ORM will hugely influence the way you build your application and although the persistence ignorance ideal should mean you can swap them with little difficulty, moving from Linq-to-SQL to NHibernate was a major piece of work, far more than I expected.
How do you take the values posted by an HTML form and turn them into a populated domain entity? One popular technique is to bind the POST values to a view-model and then map the view-model values to an entity. Since your action method’s argument is the view-model, it allows you to decide in the controller code if the view-model is a new entity or an existing one that should be retrieved from the database. If the view-model represents a new entity you can directly create the entity from the view-model values and then call your repository in order to save it. In the update case, you can directly call your repository to get a specific entity and then update the entity from the values in the view-model.
However, this method is somewhat tedious for simple cases. Is a view-model always necessary? Wouldn’t it be simpler to have a model binder that simply created the entity for you directly? Here’s my attempt at such a binder:
updated to fix bug when a child entity is changed
public class EntityModelBinder : DefaultModelBinder, IAcceptsAttribute { readonly IRepositoryResolver repositoryResolver; EntityBindAttribute declaringAttribute; public EntityModelBinder(IRepositoryResolver repositoryResolver) { this.repositoryResolver = repositoryResolver; } protected override object CreateModel( ControllerContext controllerContext, ModelBindingContext bindingContext, Type modelType) { if (modelType.IsEntity() && FetchFromRepository) { var id = GetIdFromValueProvider(bindingContext, modelType); if (id.HasValue && id.Value != 0) { var repository = repositoryResolver.GetRepository(modelType); object entity; try { entity = repository.GetById(id.Value); } finally { repositoryResolver.Release(repository); } return entity; } } // Fall back to default model creation if the target is not an existing entity return base.CreateModel(controllerContext, bindingContext, modelType); } protected override object GetPropertyValue( ControllerContext controllerContext, ModelBindingContext bindingContext, System.ComponentModel.PropertyDescriptor propertyDescriptor, IModelBinder propertyBinder) { // any child entity property which has been changed, needs to be retrieved by calling CreateModel, // we can force BindComplexModel (in DefaultModelBinder) do this by // setting the bindingContext.ModelMetadata.Model to null var entity = bindingContext.ModelMetadata.Model as IEntity; if (entity != null) { var id = GetIdFromValueProvider(bindingContext, bindingContext.ModelType); if (id.HasValue && id.Value != entity.Id) { bindingContext.ModelMetadata.Model = null; } } return base.GetPropertyValue(controllerContext, bindingContext, propertyDescriptor, propertyBinder); } private static int? GetIdFromValueProvider(ModelBindingContext bindingContext, Type modelType) { var fullPropertyKey = CreateSubPropertyName(bindingContext.ModelName, modelType.GetPrimaryKey().Name); if (!bindingContext.ValueProvider.ContainsPrefix(fullPropertyKey)) { return null; } var result = bindingContext.ValueProvider.GetValue(fullPropertyKey); if (result == null) return null; var idAsObject = result.ConvertTo(typeof (Int32)); if (idAsObject == null) return null; return (int) idAsObject; } public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) { bindingContext.ModelMetadata.ConvertEmptyStringToNull = false; var model = base.BindModel(controllerContext, bindingContext); ValidateEntity(bindingContext, controllerContext, model); return model; } protected virtual void ValidateEntity( ModelBindingContext bindingContext, ControllerContext controllerContext, object entity) { // override to provide additional validation. } private bool FetchFromRepository { get { // by default we always fetch any model that implements IEntity return declaringAttribute == null ? true : declaringAttribute.Fetch; } } public virtual void Accept(Attribute attribute) { declaringAttribute = (EntityBindAttribute)attribute; } // For unit tests public void SetModelBinderDictionary(ModelBinderDictionary modelBinderDictionary) { Binders = modelBinderDictionary; } }
I’ve simply inherited ASP.NET MVC’s DefaultModelBinder and overriden the CreateModel method. This allows me to check if the type being bound is one of my entities and then grabs its repository and gets it from the database if it is.
Now, I’m most definitely not doing correct Domain Driven Development here despite my use of terms like ‘entity’ and ‘repository’. It’s generally frowned on to have table-row like settable properties and generic repositories. If you want to do DDD, you are much better off only binding view-models to your views.
Register here: http://techdays-oss.eventbrite.com/
Sebastien Lambla (oh how I want to spell his surname Lambda, that would be so cool) who is the giant brain behind the awesome web framework OpenRasta, has organised an open source evening as part of Microsoft TechDays. There are going to be 6 talks. The current line up looks like this:
OpenRasta - A web application framework for .net
An introduction to IoC with Castle Windsor <- ME!
FluentValidation, doing your validation in code
CouchDB, NoSQL: designing document databases
Testing your asp.net applications with IronRuby
Building a data-driven app in 15 minutes with FluentNHibernate
There’s also going to be free food and drink – what is there not to like?
See you there.
I’m currently in the process of moving Suteki Shop from Linq-to-SQL to NHibernate. It turns out to be a bigger job than I anticipated, and I’ll be writing a post about my experiences soon. I’m using FNH (Fluent NHibernate) to build my mapping files rather than use the tedious built-in XML mapping. One of the big jobs I have is to write unit tests for all the mapping files. For each entity, I want to have a test that creates an instance of it, saves it to the database, and retrieves it. As you can imagine, it would be a tedious task to write all these. With that in mind I’ve created a simple NUnit test that can be reused for any mapped entity:
using System; using System.Reflection; using NUnit.Framework; using Suteki.Common.Extensions; using Suteki.Shop.Tests.Models.Builders; namespace Suteki.Shop.Tests.Maps { /// <summary> /// Runs a simple test for each entity listed. That it can be saved to the database and retrieved. /// </summary> [TestFixture] public class SimpleMapTests : MapTestBase { [TestCase(typeof (PostZone))] [TestCase(typeof (Postage))] [TestCase(typeof (Country))] public void SimpleMapTest(Type entityType) { var runSimpleMapTest = GetType().GetMethod("RunSimpleMapTest"); var runSimpleMapTestForType = runSimpleMapTest.MakeGenericMethod(entityType); runSimpleMapTestForType.Invoke(this, new object[0]); } public void RunSimpleMapTest<TEntity>() where TEntity : class, new() { var id = 0; InSession(session => { var entity = GetDefaultsFor<TEntity>(); session.Save(entity); id = (int) entity.GetPrimaryKey().Value; }); InSession(session => session.Get<TEntity>(id)); } static TEntity GetDefaultsFor<TEntity>() { var entityName = typeof (TEntity).Name; var defaults = typeof(Default).GetMethod(entityName, BindingFlags.Static | BindingFlags.Public); if (defaults == null) { Assert.Fail(string.Format("No static method Default.{0} found", entityName)); } if (defaults.ReturnType != typeof (TEntity)) { Assert.Fail(string.Format("Method Default.{0} does not have a return type of {0}", entityName)); } return (TEntity) defaults.Invoke(null, new object[0]); } } }
The core idea here is to use the NUnit TestCase attribute to run a test for each entity that I want to map. I have a generic test method ‘RunSimpleMapTest<TEntity>’ that gets called for each entity by ‘SimpleMapTest’. There’s a little bit of reflection voodoo to create and run a correctly typed ‘RunSimpleMapTest’, but the principle is simple.
RunSimpleMapTest gets a default instance of the entity class, saves it, grabs the generated id, and then retrieves the entity again using the id. This is enough to check that the basic map works and that I don’t have any non-virtual members in my entity. The ‘InSession’ method is just to save some typing, it looks like this:
protected void InSession(Action<ISession> action) { using (var session = InMemoryDatabaseManager.OpenSession()) using(var transaction = session.BeginTransaction()) { action(session); transaction.Commit(); } }
The GetPrimaryKey method is an extension method that finds the primary key of any entity based on a simple convention; my primary keys are always called ‘Id’ or ‘<entity name>Id’.
I’m using an in-memory SQLite database for the tests that’s managed by the MapTestBase base class. This is such a common solution that I’ll just leave you to Google it rather than showing my implementation here.
The last thing to note, is where the actual entity instance comes from. The GetDefaultsFor<TEntity> method looks for a method with the same name as the entity in a class called ‘Default’. The default method for PostZone looks like this:
public static class Default { public static PostZone PostZone() { return new PostZone { Name = "UK", Multiplier = 1.0M, AskIfMaxWeight = false, Position = 1, IsActive = true, FlatRate = 10M }; } .... lots of other similar methods }
Now for each entity, I simply create the ClassMap, create a method to make a default entity in the Default class and add a new TestCase attribute to my test.
The next Brighton ALT.NET Beers will be held at the co-working venue ‘The Skiff’ at 7.00 pm on Tuesday 6th April. I’ll be hosting again.
The address is: The Skiff, 49 Cheltenham Place, Brighton, BN1 4AB
The format will be the same as usual, a quick round of suggestions for topics, voting and then an evening of beer and geekery.
See you there!
Posts
