Failure is inevitable


Entity Framework - So close, but yet so far!

I decided to revisit Entity Framework for a project I’m working on.  It’s been a while since the last time I gave EF a fair shake (way back when it was first released).  I can sum up my impressions of the 4.5 version with a single word: disappointing.  EF has come a very long way since the initial release, no question about that, but there are still so many areas where NHibernate trumps it that I can’t imagine using it for a real production app.  Code First is a pale imitation of Fluent NHibernate, and EF’s schema generation capabilities are very limited compared to what NHibernate can do.  For example, I cannot do something as simple as define a unique key, nor can I incrementally update the schema of an existing database without using migrations.  The only point that I do actually like is the idea of the DbContext as a “gateway” to the database.  I think this would make it easier to enforce aggregate root boundaries when compared to NHibernate’s overly-powerful (and overly-complex) ISession interface. 

Data Access in Fail Tracker–Row-Level Security with LINQ to NHibernate

This is the third and probably final post about how data access is performed in Fail Tracker.  I’ve previously shown you the basics of how its repository-pattern based approach and how a shared base SpecsFor test fixture is leveraged to simplify testing.  In this post, I’ll show you how the decorator pattern is employed to provide simple, pain-free row-level security, ensuring that users can only see projects and issues that they’ve been granted access to. More...

Data Access in Fail Tracker

This is going to be the first in a series of short posts on how data access is handled in Fail Tracker.  Future posts will get into how the strategy works with unit testing as well as how advanced topics, such as row-level security, are handled.  Read on to find out how Fail Tracker utilizes a simple repository layer around NHibernate for all data access. More...

Getting Started with NHibernate 3 and SQL Compact

There are many posts on the web about how easy it is to get started with Microsoft’s Entity Framework and SQL Server Compact Edition (SQL CE).  This combination seems to be all the rage thanks to EF’s new “Code First” approach introduced in version 4.1.  While I am impressed with the latest version of Entity Framework, I still prefer NHibernate for a lot of reasons, and it’s actually just as easy (maybe even easier) to get up and running with NHibernate+SQL CE as Entity Framework+SQL CE.  In this post, I’ll walk you through the simple steps to get up and running. More...

Verifying NHibernate Entities Contain Only Virtual Members

One requirement that NHibernate imposes on your object model is that all public members must be virtual in order to support lazy loading.  I got really tired of getting a yellow-screen-of-death while working on Fail Tracker every time I added a new member to my domain and forgot to mark it as virtual.  So, I added a simple test to enforce the convention. Here’s the error I was getting just about every single time I added a new property or method to my entities: Annoying.  I prefer to catch things at compile time when possible, and at test-time otherwise.  I hate it when I catch something only at runtime.  Fortunately a little bit of reflection is all that’s needed to enforce a “all public methods and properties on entities must be virtual” convention: [Test] public void all_domain_entities_should_contain_only_virtual_members() { var types = from t in typeof (Project).Assembly.GetTypes() where t.Namespace == typeof (Project).Namespace && t.IsPublic && !t.IsAbstract && t.IsClass select t; var bindingFlags = BindingFlags.Instance | BindingFlags.Public | BindingFlags.DeclaredOnly; var nonVirtualMembers = (from t in types from m in t.GetMethods(bindingFlags) where !m.IsVirtual select t.Name + "." + m.Name).Union( from t in types from p in t.GetProperties(bindingFlags) where !p.GetGetMethod(true).IsVirtual select t.Name + "." + p.Name); if (nonVirtualMembers.Any()) { Assert.Fail("Non-virtual members found in domain type: \r\n" + string.Join("\r\n", nonVirtualMembers.ToArray())); } } Now when I add a new method or property to one of my entities, I’ll get a failing test when I inevitably forgot the ‘virtual’ keyword.  Yes, I should have some integration tests that catch this sort of thing as well, but I actually like this approach as it’s very specific about the convention its enforcing. 

My “NHibernate.Search and Lucene.NET” Presentation from CodeStock 2010

CodeStock 2010 is over. I had a good time, talked with lots of cool people, and attended some great sessions.  Though I had to miss day 1 due to commitments for my new job at TrackAbout, I was able to attend and present on day 2.  I’d like to thank everyone that attended my presentation, and I hope everyone took something useful away from it. I’ve uploaded my slides and code, so if you missed the session and are curious what was covered, or if you attended and want to see it again, check out the links below.  The slide deck is a little sparse on content since most of the session was me talking and writing code, but I’m working on a few blog posts that will fill the gaps (and possibly more).  Anyway, check out the links, and let me know if you have any questions or comments! Adding powerful search capabilities to your application with Lucene.NET and NHibernate Search Slides Code