Critique of Disappointing Session at TechEd

I attended a session entitled "Object-Relational Mapping As a Foundation for ADO.NET Database Access" here at TechEd.  The speaker was Terry Weiss, one of the Microsoft Regional Directors, which is kind of like being a super-MVP.  Here's the description of the session as it was provided in the TechEd materials:

ADO.NET does not offer any cursors for data manipulation. Instead, data can easily be changed by loading it into a cache (DataSet), performing several manipulations and later persisting the changes en bloc to a data source. However, the ability to physically model logical data hierarchies in this cache does not just change the programming model for working with relational data. It also poses challenges for the underlying database design. Effective usage of ADO.NET is only possible if a relational database schema follows additional rules on top of the usual requirements for normalized databases. Learn the most important rules to successfully map object models to database designs in order to make their ADO.NET experience most pleasant.

So here goes my analysis of this session, probably showing my ignorance in the process.  First, a lot of time was spent describing the object-relational problem itself.  Now I think its fair to say that some time should be spent making sure everyone knows the issue, but most people would like to spend more time on the solution.  Also, the problem is a real-world problem that developers face everyday, so its easily demonstrated with some code!  However, the speaker instead chose to talk about theory, using terms that most of the audience did not understand.  Next, the speaker gave three Visio diagrams to illustrate possible data models, and then failed to ever discuss them again.  Questions about these possible models, some of which begged questions to be asked, were merely waved over by responding that this type of issue was why this was important.  That would seem to imply that if we stuck it out we might eventually see the solution, but that was a mistaken assumption.  Then we proceed to three possible solutions, but this was again high theory, and no connection was ever made to this again.  Just when you think the real solution and code was about to follow -- no, lets not do that, lets digress into the speaker's favorite modeling technique: Object-Role Modeling.  More Visio diagrams followed with more theory, and somehow these types of diagrams were supposed to be easier for users to understand -- not!  Now that we're out of time, let's say that the solution is to use strongly typed datasets that you subclass to add the necessary behaviors.  Lots of questions seemed to bubble up about this conclusion, but again they are waved off by simply saying this is the speaker's preference and you can do it other ways now that you understand the problem.

I am definitely just starting to recently learn about object-relational mapping, so maybe I was just out of my league.  But I've seen real-world explanations of the issues and evaluated several real-world solutions, so I have a hard time agreeing that this was just my lacking.  It also seemed that everyone else was leaving in disbelief, with lots of head shaking, and no one seemed to think this was what they expected.  Now there are certainly times to talk about theory, or to stir up common beliefs, but this wasn't what was expected, and it wasn't successful in those lines either.  The speaker promised a lot -- a solution to object-relational mapping that didn't require much code or maintenance, and we got a lot of theory instead.  I was somehow expecting a discussion of various techniques that commercial O/R mapping tools use, or maybe even a comparison of some of those tools.  In retrospect that wasn't promised, but neither was what I got, and I clearly wasn't alone in that impression.  By the way, the one thing I did like was this line: "Comments are lines of code".  This refers to the belief that they should be counted if you are counting lines, especially since maintaining comments is vital if you use them at all.

7 Comments

  • I see that you've overcome your previous reticence to post a negative review of a session. ;-)





    I agree that this is an honest review, something that can be refreshing in an industry surrounded by much hype.





    Dontcha feel kinda bad for the guy, though? It's got to take a lot to put yourself on the line, and then get shot down like that.

  • The topic sounds a little academic or droll, but I read back over the description and could kind of connect the dots between what they said it would be and what it sounds like you got.





    Does that make it useful or compelling--well you were there not me, so I'll defer.





    But I don't think this was too much of a hatchet job, it clearly wasn't personal. Ideally the presenter can take it as one piece of constructive criticism, compare/contrast it with other evals and be better off and more self-knowing for it. If you find yourself in the FoxPro tent at the next TechEd then we'll both know that I was wrong there. :)

  • Well, I can say that I agree and disagree at the same time.





    The material presented was most definitely very theoretical, and the attempt to sum it all up (presto!) with an implemention thrown together with scotch tape and glue during the last 15-20 minutes of the presentation was, in my opinion, a bad choice and very ineffective. ORM and modeling are very complex topics, and a presenter's objective must be either to teach the attendees about the theory in enough detail for a complete picture to be formed in their minds, or he/she should skip the in-depth soup-to-nuts speech in favor of a more brief introduction number of learn-by-implementation demonstrations. I prefer the theoretical, but I agree it seemed like a botch job as soon as the quasi-implementation demo was thrown in at the end. Additionally, if you had read the presentation description, it most definitely sounds like an implementation class to me (the ASP.NET in the title gives it away).





    That said, I think his knowledge of the topic was pretty solid; not to mention that the class was a 400 level. He also mentioned right at the outset that the talk would be mostly theoretical and very advanced. I found it to be a nice break from the average how-to sessions that are often difficult to spot just by title alone... theory is often thrown out the window in favor of code snippets. Obviously, understanding core competencies and concepts are much more important than syntactical details for certain topics; I would argue that ORM is one of those topics.





    Lastly, I couldn't disagree more with his suggestion of simply wrapping a DataSet or even inheriting from one for the sake of strong typing (UGH!!!!!!). Using his implementation for the mapping, I believe you need to factor a given business entity into an interface defining business methods and properties, and a class that implements those methods (somewhat obvious I suppose, but he didn't even mention it???). Next, the implementing class should use a PersistenceFactory of some sort that knows how to transform a DataSet into an entity and vice versa; really, the use of a DataSet is irrelevant and should be completely hidden from the entity implementation class. The factory itself should determine the best mechanism for persistence.





    Just a few thoughts...





    Ciao,


    <joe/>

  • I wasn't there, so I don't know how bad it was, but I do know that ORM is an excellent technique to talk about both objects and relations in an abstract way that both database developers and code developers can understand it and talk about the same thing.





    The best possible way to generate an O/R model framework is to pick up an ORM model and generate both tables and constraints and code from that.





    O/R mapping is done in a variety of ways, some use datasets, some use own classes, some use a cache, others don't. One thing they have in common: they all share the same idea about 'entity', how to model these and thus how a table relates to a class. ORM is then an excellent choice, but perhaps the speaker didn't achieve to make that clear enough :)

  • Well, Frans - from what I basically seem to see here (I was not there), the problem is not that ORM may be a bad choice, but that the session was not supposed to be about ORM. It was supposed t obe about O/R mappings, and I would expect such a session to give an overview of the problem area, of possible solutions and stuff like this, instead of sticking to discussing ORM. I mean, O/R mappers are one of the most complicated thing in the industry (just look at the code you pzublicshed as a samplke for llbgen 2 - I would consider this to be a very badf implementation of an O/R mapper, very bad), and most developers need ah and to even understand the topic - so going off into ORM only, instead of the problemsatic areas you may encounter was not doing the session a facvour as it looks like.

  • I too was really disappointed with this session, leaving early rather than sit through the entire thing. 45 minutes of it was more than enough. I understood the problem, but wanted a solution - oh well . . .

  • A bit off-topic, but I've found quite a serious lack of reviews for ORM tools for .NET on the web. At the rate they are appearing today, evaluating all of them would be a mission even Tom Cruise would hesitate to take on. Has anyone read a decent review that looks at the pros and cons of the good ORM Tools for .NET?

Comments have been disabled for this content.