Dapper-Dot-Net is a simple object mapper for .NET, often referred to as a “Micro ORM”, written by the super talented folks at Stack Overflow. This post covers why I decided to use it in fabrik.
We decided to split fabrik into two applications. The “dashboard” application is where a user adds content to their fabrik site. It’s has a fairly complex domain model and as such benefits from a more advanced ORM (Object Relational Mapper) like NHibernate. This means that complex object graphs can be wired up automatically and persistence is made considerably easier thanks to object tracking and session-per-request.
The “public” application is read-only. We have a basic read model that represents just the information we need to display within the public fabrik sites.
It’s all too common to just lump these different parts of your applications together; usually because it’s “easier”. You’ve already developed your data access layer using a complex ORM like NHibernate so why not use it for displaying data on your public site too?
Well first of all, performance is a feature. My view is that performance is far for more important for site visitors than it is for site administrators. I’m not going to lose any sleep over waiting a few extra milliseconds for my blog post to save, but I may lose a few potential customers if my site takes forever to load. Remember that the public part of your site will typically get the most traffic, so here’s where you should focus on optimizing.
As I mentioned above, we have different models in the dashboard and public applications. ASP.NET MVC developers are finally getting used to creating view specific models (view models) in their applications. These view models will typically contain a sub-section of information from our data store, so why load up our complex domain model only to grab a few properties for our view?
As an example, here’s a list of fields from our “Projects” table in fabrik:
Id
Title
Slug
Summary
MetaDescription
Content
ContentFormat
PublishDate
Deleted
IsPrivate
Password
CategoryId
PortfolioId
PublishStatus
Position
CreatedOn
CreatedBy
UpdatedBy
UpdatedOn
Now let’s look at what we actually need for the public application:
Id
Title
Slug
Summary
MetaDescription
Content
ContentFormat
PublishDate
Deleted
IsPrivate
Password
As you can see, considerably less. All of these unnecessary fields contribute to network traffic and memory usage, which is especially important in metered cloud environments like Azure. In short, being lazy could be costing you money!
So I’ve covered not using the same model for both applications, but why use Dapper over something like NHibernate or Entity Framework.
Well again it comes back to performance. Dapper doesn’t do that much, and that’s why it is fast! It can execute queries and materialize results and it does so at lightning speed. NHibernate does a lot more (sql generation, object tracking, caching, associations and more). This is great if you need it (like we do in the dashboard), but if you don’t then it’s just eating into your resources.
Of course there is a trade-off in that NHibernate can make things easier. For one, you don’t need to know SQL and loading complex objects from a relational database is a breeze. But for a bit of extra work, I’d rather have better performance any day.
In my next post I’ll be covering a few ways in which you can map complex objects with Dapper and the performance cost of each.