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?