I Spose I’ll Just Say It: You Should Learn MVC

I’m never shy about my opinion – why start now? I’ve been reading a lot of posts flying about on whether you should learn MVC, Summing up the differences so you can decide when to use it, I even found a post that offers a scorecard approach! I remember reading the latter post thinking to myself “how can you possibly put a number next to Testability? And why it is only 2 more points than “using a RAD designer”? Isn’t this missing the entire point?

I felt the need to speak up a bit so I left a comment on DotNetKicks:

Please don’t use this “scoring” chart with respect to MVC and WebForms. Honestly – you can’t “score” something like “should I care about Testability” (which rates an 8) against “do I need to use this Server Control” (which scores a 10).  There are so many problems with approaches like this – really the only answer is to *try it* and see if it works for you or your org.

Today I read a post on StackOverflow which was pretty contentious wherein the author says:

I’ve been fiddling with ASP.NET MVC since the CTP, and I like a lot of things they did, but there are things I just don’t get…

<snipped ugly viewcode>

Am I doing something wrong? Because I spent many dark days in classic ASP, and this tag soup reminds me strongly of it.

Everyone preaches how you can do cleaner HTML. Guess, what? 1% of all people look at the outputted HTML. To me, I don’t care if Webforms messes up my indentation in the rendered HTML, as long as I have code that is easy to maintain…This is not!

I have definite opinions on this, and today you get to read them. Note that I pushed Scott Hanselman really hard when we wrote our book (which I think is shipping today!) to come out AND SAY SOMETHING (Chapter 3 – a discussion on MVC and WebForms – and he did an amazingly good job). It’s too easy to think “hey – I’m Microsoft – I need to stay balanced here so I don’t offend” and there’s merit to that.

I, on the other hand, think we should also be able to speak our minds. In that light, I present to you my latest effort at getting in trouble: why you need to read this post, get up, and learn what MVC is all about (if you don’t already know).

The Great Lie
WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with Webforms has anything to do with the web – you let it do the work for you.

This, friends, is a big deal (at least to me): You’re working in a lie. The web is *not* stateful and works with this stuff called HTML sent across wires using another thing called HTTP – you need to know this, love this, and feel it at the bone level. I understand this sentence right here is probably making some of you squirm – please continue squirming (I’ll wait). world

If you’re still squirming, then perhaps web development isn’t for you (meant very respectfully and kindly – not being snarky). I say this because you shouldn’t work in a sausage factory if you’re allergic to pork, beef, and ground up animal parts. Nor should you put a wig on your cat and hope that it can sing like Susan Boyle.

These are self-deceptions put in place to make you feel better about something lacking, and it’s usually not healthy. If you’re thinking that you don’t need to know HTTP/HTML to work on the web… you’re doing it again! Please see 2 sentences ago.

If you’re still thinking it – your cat needs a new wig.

MVC Is Elite-test?
I’m sure that WebForms people are probably thinking I’m being a bit of a sh** right now – and I’d like to speak to that. The title of the post here is “You Should Learn MVC” – not that you have to use it (although I wish you would – it’s tons of fun!). That’s all I’m asking – for you to learn it; I’m not telling you that you’re a bad person if you don’t use it (only that you put wigs on your cat).

MVC Is Full of Tag Soup?
Once again, I’ll say this: Spaghetti is as Spaghetti does. I don’t like to see a bunch of if’s and fors on my View the same as any other geek. This, friends, is up to you! Not the platform! Please read this: markup is up to you, as with everything else in MVC. Yes it’s not drag and drop – but nothing ever is in life! It’s new, it’s different – it’s not 1999 if only because we have the power of C# now – not VBScript.

I’m not afraid of HTML – and you shouldn’t be either. Respect it when putting code to page and use DRY as your guide. We can make it through this, together. You can bring your cat, too.

7 Reasons To Stop Calling Me A Jerk
Hopefully you’re still here, and hopefully you’re thinking “enough of the blather already – gimme something to sink my teeth into”. So here goes:

1 – Testability. No – not talking about the TDD variety, just testing in general. If you’re “not a testing person” that’s OK – the rest of the computer science world has embraced the idea that “testing what we build is a pretty good idea”. You don’t really want your clients to catch that silly “InvalidCastException” do ya? There’s LOTS of reasons to want to test – again not TDD – just good old Unit Testing! It’s easy peasy with MVC and this alone should pull you in to at least check it out – along with why testing can save you time and money.

2 – Control over HTML. I’m sure you’ve heard this before – mangled ID’s, non-validating HTML, etc. Why is this important? Because you might want to use client-side programming for something! I won’t bang this gong for too long – but it’s a lot more than “making ViewSource look pretty” – you’re communicating with super-finicky creatures (browsers) that love to argue – being able to smith the markup experience makes you a more valuable developer!

3 – Extensibility. Literally every part of MVC Is pluggable – and in the last 3 apps I wrote (Storefront, Nerddinner, and SubSonic’s MVC Starter) I used my own ViewEngine to save some time and work. I’ve spun up my own ControllerFactory so I can use IoC (which is awesome fun!) Understanding this is the keys to the kingdom for any developer! Have you ever been freaked out because you needed to use Page_PreRender to get something to load into the ControlTree properly so it will show when you need it to? MVC does not lock you into anything – you’re free to do what you want to.

4 – It Makes You Think… This is the one thing I never liked about WebForms – I never felt like I was thinking – just solving. May seem like splitting hairs, but not to me. I’d get a bit of inspiration and then try to figure out “hmmm – how can I make the form show it this way”. MVC is the opposite – the control is in your hands and you get to be free with it. You get to use your noggin! Wow!

5 – …Differently: Javascript Doesn’t Suck. jQuery, Dojo, extJS – whatever. These frameworks make client development so easy it’s actually fun. Phil and I have recently geeked out extensively using jQuery (he more than me) and I distinctly had the feeling that I’ve been missing something. Something that other platforms have had for years – the ability to make a web experience fun and magical (for a user) through client programming. It makes you think completely differently once you “get it” – and soon your server code is being drastically reduced in favor of light, clean client code (thanks to these frameworks) that work up an awesome experience. Cats love jQuery too.

It may seem weird to say it, but developers like to learn a language every few years – make javascript the one you learn this year. You might think you know it, but you probably don’t know it as well as something like C#/VB. Try to – it will change your development entirely from scheming out an interaction to how much code you write.

6 – Learning New Concepts. You’ve seen them everywhere, and seen us fighting about them. We probably shouldn’t argue so much :) but in a way, this is part of the learning process! Either way – take it upon yourself to learn some things. WebForms is a comfy blanket that can lull you to sleep over time. This has happened to a lot of us (myself included). We’re only now catching up with frameworks that have been creating rocking, compelling sites over the last few years – jog your brain! Wake yourself up and get to know the details that make compelling sites groovy! Learn the things that can help you write more nimble code – if only so you can argue from a point of knowledge!

7 – It’s Fun. This, to me, is the biggest reason. I find MVC fun because I can do what I want, when I want, how I want. I’m free to build an experience that I feel will sell my design, and I’m not hindered by a A Big Lie and a freaky cat with a wig on.

Bottom line: I’m having fun web programming again and I think that’s pretty motivating, at least for me and my cats. Yet Another Comparison, sure, but hopefully a bit more direct. You have absolutely no reason at all to not learn MVC – but I will concede there may be a reason or two for you to stick with WebForms.

I know many people might think I’m speaking for the rest of Microsoft – hardly. I’m biased and, more importantly, I actually still have my very own brain which forms its own thoughts! I love MVC and I think you will too – just please, please try it before you form an opinion.

Posted in Uncategorized | 11 Comments

Patterns, Purists, and Sinkholes

Before I was a geek, I was a Geologist. A Geophysicist to be precise – but mostly I just tell people I was a Geologist. I worked a lot with environmental cleanup, but I also spent a lot of time doing what’s known as “Geotechnical” work – the stuff that happens before buildings are built and holes are dug. It can be kind of boring, but it’s crucially important.

One day I was sitting in our lab with some dark Bay Mud in a crucible, slowly adding water in measured doses and then pouring the mud through a screen and weighing out differences. I won’t bore you with the details – I’ll just tell you that I was 23 and cranky that this is what my career amounted to – a bunch of rigorous nonsense where I got to weigh mud.

I started complaining and mumbling and my boss (who was a patient to no end) filled me in on some details:

What you’re doing, Rob, is measuring the amount of clay that’s in soil at this site. The water you’re using dissolves the clay, and the screen removes the sand from the clay/sand slurry that you’re mixing in the crucible. We need to know how much clay is in the ground so we can know how much it will swell in the winter when it rains. This will keep the building from expanding/contracting and falling over into resultant sinkholes.

I won’t bore you with the rest. Suffice to say this: building things has been around for a long time, and it took a WHOLE LOT of buildings falling over before some smart guys (let’s call them purists) got together and said “we should do it this way”. They then convinced their local governments and boom, the building code is born.

Geek Building Codes
My house is built on volcanic clay that’s been amended to some percentage of clay/sand/aggregate so that my house can stay standing for at least 50 years (not counting hurricanes). I’m pretty grateful for that, because I *absolutely know* that if the builder didn’t need to do it, he wouldn’t. Amending and backfilling that much soil sucks, and I don’t want to depend on the original builder to get that right (cause I tell ya, they skimped on a whole bunch of other stuff that I’ve been fixing!).

Our industry doesn’t have building codes and as such need to compare what we make with what other people make in order to gauge how good our stuff is. That usually results in purse fights and secret clubs, and rarely does much for us as an industry and I can see why people might shy away from engaging in these conversations.

But to stop asking is to stop learning. Worse yet – to suggest that it’s not even worthwhile is utterly absurd. It drives me nuts when people write posts that suggest that principles and standards of quality are cumbersome (even if they didn’t mean to suggest it – which I don’t think Jeff did – read the comments and you’ll know what I mean):

The bigger and more grandiose the set of rules you come up with, the more severe the danger. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..

Pretty soon you’ll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules! And, of course, a critical mass of programmers patient enough to read Volumes I – XV of said rules. You’ll also want to set up a few messageboards for these programmers to argue endlessly amongst themselves about the meaning and interpretation of the rules.

Now let’s transpose this sentence a bit, and apply it to an industry that’s just like ours (the building industry, as discussed above), but a whole lot more mature (my replacements in brackets):

The bigger and more grandiose the set of rules you come up with [for building houses], the more severe the danger [of never getting the house built]. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..

Pretty soon you’ll find yourself believing that every possible situation in [building a house] can be prescribed, if only you could come up with a sufficiently detailed set of [plans]! And, of course, a critical mass of [builders] patient enough to read Volumes I – XV of [the local building code]. You’ll also want to set up a few [city building inspectors] for these [builders] to argue endlessly amongst themselves about [whether the builder built your house properly].

Properly Breaking The Rules
Don’t get me wrong here – I’m not a complete dork espousing that we need to walk in step to a set of software building codes. People break the rules when building houses all the time – but they do it from a perspective of understanding what it is they’re breaking. For example – one of the greatest architects of our time (Frank Lloyd Wright) loved to break rules and even have fun with the concept – even creating things with no right angles at all.

I love breaking the rules. I can feel Steve Harman sweat a little bit when I write code ahead of a test and I’m absolutely sure baby Alt.NET cries a little when I embed a SQL statement in my code (which yes, I just did the other day and I’m damn proud of it – kids dont’ do this at home, I had my reasons). The difference is that I KNOW the reasons why this is bad – and I also know why I did it in the first place. I was able to work through the issues and ultimately decided that breaking some principles would be just fine in my case (and no, I’m not going to tell you what it was that I did – but you’ll dig it when you do see it).

I don’t like being negative and I feel like that’s what this post is – so let’s see if we can turn that frown upside down if only because I like Jeff a whole lot and I feel like I’ve been picking on him of late (that last post was all in good fun I should point out) – and when my computer blows up I’ll need his help some day :). I do know what Jeff was after with his point and I’ll go so far as to defend him on this – that blindly following rules instead of your skills is actually a detriment. But your skillz gotta be good if you’re going to diss the Gang of Four and Uncle Bob! What Jeff might have wanted to say is:

LEARN THESE RULES FIRST AND USE THEM! Then you can decide if they don’t fit what you’re doing!

The people that made those principles up are quite smart, and have been doing this for a long, long time. Please don’t take Jeff’s post as the 3:00 school bell (where you run out to the parking lot and smoke cloves and drink wine coolers with your emo friends) – you’re *not* excused.

Posted in Philosophy | 28 Comments

5 Secrets To Ninja Writing

Sometimes I find myself with absolutely nothing to say and yet decide to write a post anyway. Do you ever have that problem? I sure do – and I thought it might be fun to share some secrets with you about how you can salvage the day when you decide to write a post, and have nothing to say.

I found this quote of a quote by Jeff Atwood to summarize nicely my feeling on blogging and inspiration:

Consider your writing a natural extension of your spoken conversations. If you aren’t comfortable reading it out loud, rewrite it until you are. In the words of Elmore Leonard:

If it sounds like writing, I rewrite it.

Secret #1: Find a good quote, quote it, restate it, and revolve your post around it. For added effect (in case you feel like you really can’t get your/their point across), make sure to (Secret #1.5) simply bold the summary of the sentence, which gives it a weight of summarily representing the original quote in a different manner, rendering the initial thought yours.

Make sure to follow up the initial quote (which should establish the point of the post) with another quote/summary pairing that supports it and allows you to be clever – even if it ultimately distracts from the original point. Rob Conery states this very concisely:

Make sure to follow up the initial quote (which should establish the point of the post) with another quote/summary pairing that supports it and allows you to be clever – even if it ultimately distracts from the original point

Secret #2: Inject a completely random image of something that’s supposed to be symbolic:

Bond, James Bond

Secret #3: Should you lead off the following paragraph with a question? Probably not – but if you’re worried about this you can always answer yourself with a bolded sentence, thus creating and disposing a nice recursive black-hole paragraph in one pass. For good measure, make sure you follow this up with another long quote from someone who’s books you read a lot of:

Now wait a minute, Mr. Socks Fox!

When a fox is in the bottle where the tweetle beetles battle
with their paddles in a puddle on a noodle-eating poodle,
THIS is what they call…

…a tweetle beetle noodle poodle bottled paddled
muddled duddled fuddled wuddled fox in socks, sir!

Fox in socks, our game is done, sir.
Thank you for a lot of fun, sir.

Secret #4: Lotsa Links. It’s important after a quote (especially one with the magnitude of Fox in Socks) to pick up the thread and carry it forward to the next idea: Make sure you have a plethora of links to other important things you’ve written. Especially if they’re on the topic at hand. Self-linking is crucial to driving more hits to your blog. Jeremy Wagstaff of loosewire puts it very well:

It’s a nuisance more than a crime, but to me it still undermines a central tenet of the web: links should be informative and not misleading. If you are linking to anything other than what your reader would expect, then you’re just messing around with them.

Clearly Jeremy understands the impact that proper self-linking can provide, when done properly.

Secret #5: The finish of the post is your money shot – the thing that your readers will remember as they warm up their keyboards to tell you that your blog is starting to suck and your writing has become stultifyingly formulaic and boring. Make sure that you restate what you’ve said, and (keeping in mind Secret 1.5) finish up by confirming that the previous 5 or so minutes were a complete waste of your readers time. Or just ask them what they think and be sure not respond to comments :).

Posted in Uncategorized | 8 Comments

Software Design Kuleana

Last year I tore apart my kitchen with a sledge hammer and a crowbar. I knocked a wall down, ripped out the old, crumbly cabinets, and tore up the 20-year old vinyl flooring that was discolored and horrifically 80’s. I specifically remember using my crowbar to pull off one section of cabinets, sawing it completely in half with my Sawzall, and then flinging it off my lanai, crashing into the ground below, exploding into broken pieces of Bad 70’s Kitchen Cabinetry.

Out of this came an awesome kitchen remodel that we worked really hard for:

From House Pics

Awesome Except for One, Massive Thing
See those counter tops? They’re concrete. A choice my wife and I made because we love the look and also because we wanted to be as “green” as possible. Our contractor was highly recommended (friend of a friend) and his price was right – not the cheapest but within our budget. He came in and spent about 2 hours with us one day, meticulously laying out measurements and “layouts” that would help him create the cast. This is when I started to get uneasy.

“I thought you were going to build the forms right here and and poor everything in place so we won’t have seams and everything remains level” I asked.

“Sure, I could do that but if I use forms then I can cast everything upside down in my workshop with this special material that will leave a nice, shiny surface that won’t need to be polished endlessly. Saves on hours and also keeps the mess down – otherwise I’d probably make a mess of your kitchen. Also, if any part of it breaks in the future, you can just replace a section and not the whole counter”.

Saving money and mess – sounded like a good argument. Also it seemed like a good “maintainability” plan which appealed to my geek side.

On the day he delivered the counter we found out he had to create more sections than he anticipated, due to weight and fragility. The section next to the sink was liable to break during installation, so he played it safe and made one section into two. This made me uneasy again – the seam was right down the middle of the sink and seams and sinks don’t make good friends (food, water, etc). But I trusted him, so on we went.

Once all the sections were fitted in, the contractor sat there and stared at it and said the words all homeowners dread: “hmm, that’s a little bigger than I thought it would be”. And thus started our adventures in counter-top pain. Over the course of the next 6 months everything with the counter went to hell:

  • He used the wrong edging on the forms so that the seam edges were rounded (normally you only want the outer edges of the counter to be rounded so they’re not sharp). This caused the seems to have a 1/2 inch gap – not good.
  • He filled the gap using concrete putty, with his fingers. It looks like my 6-yr old did it.
  • He punched a hole through the section next to the sink when he was drilling the supports (from underneath) for our dishwasher. He tried to patch it but it didn’t work since it looked like… a patched hole in the nice concrete counter. He hired a “touch-up” artist to paint over it and it looked OK for 4 months until the paint started to peel off. It wasn’t supposed to peel, but it did because …
  • He forgot to seal the countertops. The first time I cooked on the stove I stained the counter around it with a nice dark halo, caused by the exceedingly greasy stir fry I made.
  • When he ultimately sealed the counter tops, he used the wrong sealer. It wore off in 4 months (it was water-based and they don’t work so well when you wipe counters off with water-based water on a towel) and pretty soon we had glass rings, metal leachate rings (white rings from metal contact), and juice stains.

Long story short – he eventually stopped returning our calls and we didn’t pay him. Everything came to a head last week when he asked to get paid (believe it or not) and I basically told him:

I’m not paying you for effort, I’m paying you for countertops. I don’t have those – so you don’t get paid.

He then said “oh well, I guess we’ll call it a writeoff and a hard lesson learned.”. Which means I ultimately lose in this deal as I now have to clean up his mess (and pay someone to do it). I might just whip out my sledge hammer and crowbar again…

Why I’m Telling You This Story
How many times have you gotten into a scrape with a client or boss? Have you ever grumbled when they’re seemingly unreasonable and tell you what technology to use? I have, and it’s no fun.

In this case my contractor was focused on how best to get things done with minimal “friction” and maximum maintainability. Believe it or not – sometimes that kind of thing may actually hinder the delivery of what your client wants. For instance:

  • How many times have you shaved the scope because of a particular architectural design choice?
  • How many times have you had to rip out a technology set at midnight and then code all night long to get your client’s site back online?
  • How many times have you talked a client out of a feature because it wouldn’t fit with your design choice?

If you’ve said “never” to all three of these – I applaud you (I can’t do that). Or maybe you should go look in the mirror and see how long your nose is :). My point is that the client ultimately trusts you, but that trust has NOTHING to do with technology and everything to do with delivering what they expect to see. Mastering this understanding is at the core of what we do, and almost always at the core of every client disagreement.

If you’re about to tell me “yes but clients always change their mind” – I’ll agree with you. I’ll also say that since you know this, you should be ready for it. In my case I didn’t change my mind on my counters – it was changed for me (which happens a lot too). The contractor did his best but I didn’t get what I wanted – nice countertops. He didn’t get paid – the equation is simple.

Now I could have sat there and told him “no – I don’t want sections, I want you to cast it in place. I also want you to make sure to use small screws when putting in the dishwasher, and also make sure you use a top of the line concrete sealer” – but should I have needed to do this? Moreover – I didn’t even know these were issues until they became issues.

This mess could have been avoided if…

  1. We had a better dialog. I should have made it clearer what I was willing to compromise on, and what I wasn’t. Likewise he should have explained a bit more (visually) on what I was going to get out of the deal.
  2. He had a better work ethic or “Kuleana” – a personal responsibility. He should have replaced everything the minute he realized how bad it was. I let him know, believe me, and he chose to walk the other direction. I could have (probably should have) chased him down to make things right, but it’s a small island over here and I figured he’d be back for his money (and he was).

What’s Your Kuleana?
All the things we argue about on Twitter and in blog posts, your “Kuleana” is primarily to your client, not yourself or the industry at large. Hopefully the two go hand in hand, but if you find yourself saying “my client doesn’t get it” or “man I wish they let me do X,Y,or Z” then you need to reflect on what it is YOU are doing to foster this situation.

One of the neat things DDD has is the Ubiquitous Language – the structured dialog that builds client understanding. I think this is just a fancy word for “being a good consultant” – something that you are or are not. You’ve heard it before, but it’s very, very true:

Being a good [relevant partner in a relationship] requires you to listen

Marriage, friendship, consulting, blogging, Twitter, bowling league on Wednesdays. You have to have listening skillz or you’re not a good [relevant partner in a relationship]. So many client failures can be avoided by realizing the burden of listening is on US, not them. We’re here to solve their issues – it’s our Kuleana.

Posted in Philosophy | 5 Comments

More OODB Crazy Talk

I listened to the Alt.NET Podcast the other day and there was a crazy guy who sounded an awful lot like me on there talking about Object Databases. Doesn’t he know they’re not cool? He must have some kind of career death wish – the need to trash his reputation (or create flame-bait) in the name of Something Fun To Do. I’m not sure he elucidated his thoughts very well, so I’m here to help him out with some details that many of you might not be considering.

There’s a Difference in Your Data
One major point that didn’t come out in the discussion until the end was the idea that your application deals with different “types” of data at different times. endless_summerYes, I know this sounds weird, but consider it for a moment in terms of the Road Trip. Let’s roll back to college for a moment – your buddies want to head to Ensenada for the weekend, and you need to figure some things out before you go:

  • There are people involved – how many are coming?
  • Depending on the amount of people, you’ll need some cars to transport them
  • No road trip is complete without roadtrip tunes – you’ll need some groovy tunes to listen to
  • Junkfood! You have to have some of that for sure!
  • Camping supplies (which usually is a towel to sleep on and more beer to pour over the little boxes of Cap’n Crunch – called “Crunch Bombs” – in the morning)

That’s probably enough. In this we have our Ensenada Domain Model – all of the “objects” we’ll need to have a good time on our Road Trip (I’m sure you can think of more, but I’d like to keep this post PG, at least). These objects comprise what I’ll call “Functional Data” – the stuff you need for your application to properly engage the user.

The next type of data is “Derivative” or “Resultant” data – the stuff that comes out of the application experience.  You can think of this as the result of a User’s experience with your application – the choices they make, the stuff they view, the behaviors they exhibit when interacting with your creation. This type of data has no upper bound, is time-stamped, and is ultimately what the stakeholder cares about the most – I’ll come back to this.

On our Ensenada trip – the “resultant” data is what happened on the trip itself:

  • The midnight swim in in various states of dress
  • Fish tacos and Coronas after 6 hours of surfing, when [Slacker Friend] passed out next to the fire after telling everyone all day how he would rage into the night and through to the next day
  • Watching the full moon rise as you’re falling asleep under the stars
  • Waking up with ocean dew on your face, slamming some Crunch Bombs, and heading out for Dawn Patrol with your friends
  • Hanging with your best friends and knowing that you’re in college and this kind of freedom won’t last forever

This type of data revolves around the experience – the stories you tell afterword, the pictures you might share, the things you see, etc. Pulled together these things create the “value” of the whole enterprise – it’s Why You Did It In The First Place. This type of data is what the business guys are after and what they care about the most.

Put The Data Where It Belongs
The two kinds of data I’m talking about here sort of have their own needs in terms of storage, which you can probably guess:

    1. The Ensenada Domain Model belongs in something that can support an OO structure the best
    2. The Ensenada Experience Data belongs in something that can support a lot of data and build interesting stories (aka “queries”), with a great degree of fidelity.

In short: put the domain stuff in an OODB, put the “result” stuff in a relational (or OLAP) system.

Some Real World Examples Please…
Let’s put this in concrete examples, keeping in mind that an OODB and RDBMS can exist together quite happily:

  • Commerce: Products, Categories, Sales/Coupons, Users – these are domain constructs subject to complex relationships. Put em in an OODB. Orders, statistical tracking (such as times viewed, added to basket, etc) etc. are “resultant” data – stick it in an RDBMS.
  • Blog/Forums: Users, Posts – domain data. Comments, Pingbacks, Links, Ratings – resultant data.

These examples are of course very arguable :) and might change based on your needs for an application. The bottom-line premise sort of remains the same:

ORMs can’t hit the 100% Object-Oriented Domain Model for a reason: Object Oriented Design != Relational Design. It just is. It’s time to frame persistence in terms of the design required for the data it’s storing.

Note: I am very aware of that many of the tools out there (NHibernate in particular) can work around a lot of these issues. If you know NHibernate well enough to figure out that you have a problem and how to fix that problem. I say why worry about it? Sure SubSonic is fun and awesome – it’s my baby. I think it would play very well tracking how many Fish Tacos and Crunch Bombs you consumed on your Ensanada trip – so use it to do that!

One thing I hear quite often (and I’ve read a good many posts on OODBs since the Alt.NET podcast) is that people don’t think OODBs are performant (this word brought to you by Jon Galloway). The truth of it is that in most cases they will out perform most RDBMSs – IF you use them properly. The same can be said of an RDBMS … it’s all about proper use of technology.  These things have come a long way and running “deep graph” queries doesn’t cost all that much, as long as you play by the rules of your OODB vendor.

But this brings us back to the overall suggestion here: if you’re running Deep Graph queries on your OODB, chances are you’re not storing your data in the right place! OODB queries should really be quick access of objects for your Domain to function – not deep dives into a User’s order history. That’s for the relational system!

If you’re offended, freaked out, excited, nonplussed, hung over, or otherwise maxxed out in one way or another after reading through all this – hooray! Crazy Talk is good, usually, for one of two things:

  1. Testing what we believe, and affirming that The Way We’re Doing It is Right For Us
  2. Testing what we believe and offering a Whole New Way To Do Something That Makes Us Feel Better

What do you think? And as always, the more detail you can offer, the better! If you think I don’t know what I’m talking about – you’re most likely correct.

Posted in Crazy Talk | 1 Comment