Tim Barcz : NHibernate

The Database Doesn't Matter or Don't Pollute Your Domain

Tim Barcz — Thu, 16 Jul 2009 03:01:00 GMT

Last week I spoke at CRineta (Cedar Rapids Ineta) on NHibernate. It was an introductory topic on NHibernate and as such I talk a bit about persistence and what it is. I find that it is worth defining persistence because, while it exists in most/all applications, many of us view persistence so very differently...as I found out last week.

I defined persistence (a la NHibernate in Action) as:

"Persistence allows an object to outlive the process or application that created it."

In my applications, I prefer the application to represent the real world concepts and have a very solid "domain". (note: that I hesitate to even use that word as it is so globally applied these days to mean just about anything.) When I presented this view in my talk it was received with some less the enthusiastic sentiment from a few in the crowd. The primary complaint from the unimpressed in the crowd was that generally "the data is the backbone of the application" or "its all about the data". While it's true that data is important, VERY important in fact, it shouldn't be the primary driver of you application, the objects/concepts should be.

Over the last few years I've been focusing on having a less data centric view of the applications I work on. Instead focusing on objects and concepts and the needs of the application. So far this view has yet to be a disservice to myself or the applications I work on. Most practically this means I don't think about my C# objects in terms database tables and rows of a table. In the easiest example I can give about deriving your domain from your database I share a problem found in LINQ to SQL. If we were doing a blog application and wanted to use LINQ to SQL we'd have classes for blog, post, category. What you would also have to add with LINQ to SQL is a PostCategory object, to represent the idea that a post can have multiple categories and a category can have multiple posts. What's a PostCategory? There's no such thing in the real world. A post has categories. A category has posts. PostCategory is not a real object. LINQ to SQL causes your domain model to suffer in order to achieve persistence. (Note: there may be a more elegant solution to solving this problem as we abandoned LINQ to SQL within days of discovering this.)

There is no usefulness in just "having data". Therefore instead of speaking in terms of tables, rows, and columns, we should instead talk about objects and their interactions. For example a row in a table most always represents some idea represented in software, a users account information, an order with products purchased. Those pieces of information exist so that they can be retrieved at a later date and operated upon in some fashion (see the definition of persistence above). For the user it means being able to log in. For the order it means displaying an status, invoicing, fulfillment, whatever. The data stored in a database almost always represents some notion of "something" (sorry to be vague here), so let's talk about that "something" and NOT the data.

Should the database be optimized? Absolutely. Should the database be indexed and placed in the proper file group to achieve best performance? Absolutely. The database specific concepts however should never bleed into you application code. If they do, you're polluting you application/domain and working against the long term health of you project.

In closing, I ultimately wasn't surprised I was met with skepticism. It's a long held view by many developers and is supported heavily by the Microsoft tooling. It won't change tomorrow or the next day. It will change slowly over time one developer at a time. Ask yourself, when you open a new application are you thinking databases? Columns? Indexes? Do you need to change how you think about your application?

NHProfiler - An Early Look

Tim Barcz — Tue, 09 Dec 2008 07:09:17 GMT

Over the past week I've had the distinct opportunity to have a first-hand look into NHProf, Ayende's upcoming profiler for NHibernate. It's been an honor to be part of the team that is putting NHProfiler through its paces. While NHProfiler is still in private beta it is very impressive and I want to let you peek inside.

This evening I decided to sit down and spend some time poking around an application and watch NHProfiler to see if anything seemed out of sorts. Here's what I found:

Easy To Understand

You can get by without purchasing NHProf, from what I see there's nothing you can't "figure out" yourself. NHProf is a lot like ReSharper or CodeRush, you can get by without it, but why would you want to? Here's what I mean, you can pop open SQL Server Profiler and see what is being executed:

That's messy but take a look at how NHProf collates the data:

Relevant

You can sift through the SQL Server Profiler trace if you'd like to but NHProfiler does a great job in giving you the same information, just presented better.

From this view I can see that five queries were run and I can see that three of the same queries are being issued which might point to an area where there is some tweaking to do.

Performance Gains

We all want our applications to run faster. We want speed and performance but often times its takes quite a bit of time to find performance problems and their subsequent fixes. NHProfiler allowed me to very quickly find some queries that didn't need to be executing and tweak some code to eliminate those calls. Since I can see the code that NHibernate generates I can also make modifications to query I'm submitting to NHibernate for further performance gains.

In a very short amount of time (the writing of this blog post has taken several times longer) I was able to reduce reduce data access time by a factor of nearly 10. How do I know that, I have the hard data to prove it.

Before:

After:

Conclusion

If you use NHibernate, NHProfiler is a must. By using NHProf to observe my applications I'm able to save my time and not have to burrow through SQL Server Profiler or wonder what is going on at the data level. I am quickly able to observe what is going on and when and make any necessary modification and then observe the outcome. While you can use Visual Studio without ReSharper or CodeRush many of you out there have found you just don't want to. After using these productivity tools you find that you're able to work with less friction. NHProfiler is the same way, you can work without it, but I highly recommend against it.

Keep your eye on Ayende's blog for information coming soon.

Alt.NET Austin - Workshops Day 1

Tim Barcz — Sat, 01 Nov 2008 06:17:40 GMT

I'm in Austin, Texas for the Kaizen Continuous Improvement Conference this weekend. One of the very cool things the organizers did for this event was offer two days of workshops before the conference. While I'm excited for the conference itself, much of my excitement for the conference stemmed from these pre-conference workshops. Yesterday I went to two workshops, both of which should be online at some point.

Advanced NHibernate - with Ayende Rahien

I was a little leery of this one given our seemingly trivial usage of NHibernate. I was pleasantly surprised to see how much of this was perfectly timed for where we are at. Oren went into great detail on various parts of the NHibernate and it's contributing projects. He spoke a bit on caching and performance optimizations/pitfalls that you generally have to watch out for. Quite possibly the coolest feature was getting to see NHibernate profiling application that Oren is working on. This won't be a free tool but the price from what I've heard from Oren will be very reasonable (I am not saying the price since it may change). With NHProfiler you can see all the queries that get executed from you application. It even has alerts built in, such that if it detects a problem (ie. Select N+1) it will let you know. Without hesitation, if you're using NHibernate, buy NHProfiler when it comes out, it is easily worth it.

The most important concept that I got from this session is how powerful NHibernate is. People can fight ORM, roll their own solution, or write their own T-SQL but when you see what NHibernate has to offer it seems ridiculous to choose any of those options. Two little known NHibernate features you may not have known about that I've found very cool:

NHibernate Search : Leverages the open source Lucene.NET implementation and keeps allows you to do search which have performed poorly in the database against a very fast Lucene index.
NHibernate Shards : Written by Google this allows you to scale across a number of databases. I won't delve into sharding here but you can read up on it on wikipedia.

DDD Chalk Talk - David Laribee

I was very interested in this chalk talk since the name seemed to indicate we'd get a chance to have an open discussion about DDD and how one would approach DDD in their domain. This talk seemed to have peaks and valleys. It was no fault of anyone in the talk, but DDD seems to be one of those topics where it becomes extremely tough to follow once you get outside of what you know. The topic of aggregate roots and contexts were quite helpful. I found it encouraging that ideas that I have interpreted from the book seem in line with what David Laribee demonstrated on the white board. I'm only a few chapters into the book and am absorbing as much of the DDD concepts from those who are ahead of me on this path. I'm encouraged to see where others have taken it, the value they have found in it, and what it could mean for our application(s) in the future. Just have to keep reading and learning.

Quite a lot for only the first day of a multi-day conference. For those of you who aren't here in Austin but wish you were, keep an eye out for videos of the many presentations that my pop up. I will update this blog if/when I see them appear online. There was a lot of good content coming out of these workshops and it'd be a shame to have the content limited only to those in attendance.