Object Persistence in .Net (PADNUG 8/31/05)

I have very little free time these days, but the timing/topic/speaker were the right combination to motivate me to go to my first PADNUG (Portland area .Net user group) meeting last week. We're using NHibernate for NetworthIQ and I wanted to hear more opinions about it from the community. Plus, I didn't want to miss the chance to see Ted Neward speak. I took a J2EE class from him a couple years ago and was utterly amazed at how much I learned in that week. Ted is one smart dude, he's probably the brighest developer I've come across in my career. Oh yeah, and since Ted has stated that "Object-relational technologies are the Vietnam of the Computer Science industry," I knew he'd have some interesting thoughts on the subject.

In the spirt of agile development, Ted gave an "agile" presentation on Object Persistence in .Net. Below are my notes, most of which comes from from his "agile" PowerPoint (Notepad) presentation used for the talk.

Object Persistence in .NET

Key Points

• Most modern languages are object oriented
  
• Objects (fields) --> databases (columns)
  
• Should match up? Not so much (object relational impedence)
  
• The RDBMS is governed by the relational calculus (Chris Date)
• When trying to bridge from model (object --> hierarchichal, object --> relational) you run into object impedence
  
• Models don't slave well to other models
  
• Microsoft Research is tackling it

ADO.NET issues

• ChrisT sez objects are cooler than relations (we work with objects mostly)
  
• no compiler support for when you f*ck up your SQL (latebound)
  
• dangerous security implications (SQL injection)
  
• tedious (lots of typing)
  
• smells of DAO (rows and columns not objects)
  
• type mismatching
  
• nulls/nullable/nullable types (fixed in 2.0, right?)
  
• connections and connection pooling
  
• transactions
  
• entlib can help (not an end-all)
  

DataSets

• a big bowl object: DOM for data people
  
• disconnected (+ connection-management, sort of)
  
• in-memory options
  
• "strongly-typed" DataSets aren't (?)
  
• boxing/unboxing overhead
  
• memory footprint (God help the PocketPC)
  
• eager-fetched data retrieval strategy
  
• Does it provide much more than ADO.NET (not really)
  

ActiveDirectory

• some support for early-bound
  
• not general-purpose
  
• dynamic schema/schema manipulation after deployment
  

OODBMS

• no object-relational impedance mismatch!!
  
• behavior and data combination/disconnect
  
• whose definition of OO do we use?
  
• how do we import into OODBMS
  
• reporting? It's up to you to do it all
  
• data access approaches mean object access approaches
  
• have to navigation objects as opposed to the SQL join approach
  
• dasBlog, I mean regexp, kicks ass, sez ScottH (don't ask about reporting on blog entries)
  

XML and related tools

• querying/reporting difficult across files
  
• "objects and xml go together like chocolate & PB" (nope)
  
• xml is hierarchical, objects can by cyclical
  
• XML needs single root, SOAP provides SOAP body element as a cheat (SOAP 1.1)
  
• Schema committee wrestled with it for 2.5 years and punted
  

Nhibernate

• (there are lots of ORM tools, but we mainly discussed NHibernate)
  
• O/R-M: match objects to database stuff
• Reflection-based schmutzer (serializer)
  
• lazy vs. eager evaluation (either way can run into problems with memory issues for eager and db/network overhead for lazy)
  
• Is it worth the price (saved dev time) for not being able to decide when to fetch data
• question of how deeply coupled (at some point you have to be coupled)
  
• is it too chatty? Will it scale?
  
• prefer pulling more data (overhead of making calls to db can be costly)
  

C-omega

• Microsoft research project
  
• elevate relational concepts to the language
  
• compiler support
  
• ORM need not apply
  
• when you gen the code, the types are created

Overall, it was a good presentation. Not a lot of new stuff for me. Most of this I had already known from my previous research on NHibernate, but I picked up some tidbits that you can only get in a presentation/discussion format, and not just reading. C-omega looked pretty sweet, but anything like it in a production release is a long ways out.

The biggest thing I took away is that ORM's can be a big help, but be wary, they're not perfect. If you own the database schema, and it's relatively straightforward (i.e. don't have to make seven joins to get your data), you can have good success with them. I'd say that matches up pretty well with my experience using NHibernate so far. For NetworthIQ, we'll have to revisit the scaling issue at some point, probably adding some profiling and doing some more performance testing. But, so far I'm pleased with it.

Tags: padnug nhibernate ORM