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

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?


Posted 07-15-2009 10:01 PM by Tim Barcz
Filed under:

[Advertisement]

Comments

Harry M wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-16-2009 4:56 AM

I massively agree with this, but not sure about the the PostCategory thing. If I get you correctly, you are saying L2S can't do many->many mappings, in which case you end up having to create a PostCategory object to represent the join table, which means you have had to change your domain model because of a limitation of the ORM layer you are using.

I get the feeling that the many->many mapping is a slightly hacky shortcut. If at some point a requirement comes up to store TimePostAddedToCategory and UserWhoAddedPostToCategory, you'll need to drop your many->many, and create the PostCategory class with CreatedDate and CreatedBy properties. Its just that in the domain model you've started with you've been able to get away with out creating it because of NH's many->many feature, but it implicitly exists.

PS there is some kind of comment bug which is forcing me to fill out the Email notifications field before I can post!

Brendan Tompkins wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 10:29 AM

TEST

Eric Sabine wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 10:34 AM

Tim,

I think I get what you're saying about the PostCategory example.  It's not that you can't do it with LINQ to SQL, you can, I think what you're trying to get across is that the object "PostCategory" is just a silly object.  That it doesn't represent something physical like Blog, Post, and Category, or better said, it's not a "Domain" object.

I think perhaps you should have put in one more paragraph to explain how to live without the PostCategory object, e.g., to show where the behaviors should be placed.  

Thoughts?

Tim Barcz wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 11:52 AM

@Eric,

Yes, "PostCategory" is a silly object because in the real world no such thing exists.  I would say to you "This post has the following categories" or "In the category of 'NHibernate' there are four posts"

Tim

Hudson Akridge wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 12:04 PM

This is a great article, and hope more people pick up this train of thought. My background being on the DBA side, it was extremely hard for me to overcome thinking about building a solution from the data layer on up, rather than the domain layer down.

Harry M wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 12:18 PM

Perhaps PostCategoryRelationship is a better name. Like I said before, sometime the relationships joining tables have properties other than Table1Id and Table2Id, and at that point you need to model the relationship as a domain object. NH just lets you get away without doing it straight away where L2S doesn't.

Tim Barcz wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 12:33 PM

@Harry

What is a "PostCategoryRelationship" it's not a real thing you and I would talk about.  Other columns in a many-to-many are fine, the only thing is that the data there represents some real-world concept...what is that concept? Identify it and talk about it in those terms.

Harry M wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 1:02 PM

We might talk about when the post was added to the category (and vice versa) and who did it. In which case we are talking about the relationship between the two, and the PostCategoryRelationship becomes a domain concept.

Hudson Akridge wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-17-2009 2:45 PM

Harry,

I'd argue that even with a timestamp, it's still not a domain concept. Only exception being if you're using that timestamp to perform some sort of business action (validation or business dsl event notification). Otherwise it's just a reporting component/implementation detail. The domain would never know about the "Timestamp".

Now, if you start tracking additional information on the PostCategory, and a PostCategory performs some function in the domain (remember, a class is both data *and* functionality), then it would be it's own class in the domain.

Harry M wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 07-20-2009 6:05 AM

I guess all I was trying to say is that there exists a notion of a relationship between two items in the domain that is implicit if you use many to many, and needs to be made explicit if you don't have many to many capabilities in your ORM.

I don't think the cost of the having the relationship object is so great that it totally invalidates L2S as an ORM layer. Also, the L2S stuff slightly muddies the waters of the rest of the posts sentiment ("think model not data!"), which is a really important point.

I'll post fix that with a big IMO, and we can leave it there!

bookmarking submission wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 01-18-2013 2:23 AM

V1TmYk This is one awesome blog post.Much thanks again. Fantastic.

buy imitrex online wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 02-14-2013 2:27 PM

XyV647 I value the post.Thanks Again.

buy social bookmarks wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 03-23-2013 12:05 PM

WSGNBL Thanks for sharing, this is a fantastic blog.Really thank you! Really Great.

comedy shirts wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 04-06-2013 4:05 PM

Enjoyed every bit of your article.Thanks Again. Much obliged.

best linkbuilding wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 10-01-2013 2:08 AM

n95b7s Thanks-a-mundo for the article post. Cool.

matt wrote re: The Database Doesn't Matter or Don't Pollute Your Domain
on 10-17-2014 1:29 PM

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)