Presentation and Code from my Intro to O/R Mapping Talk

Thanks to the Atlanta C# User Group for allowing me to present last night.  I'm a terrible speaker, in spite of years of teaching practice (former math professor and grad student before that), so I'm content if people learn something even if they aren't impressed by my speaking skills (or lack thereof) -- and it sounds like I did accomplish that goal from the feedback I've gotten.  Getting up in front of a user group like this one is a lot more awkward than teaching math though, since I knew I knew far more math than my students ever would, but I'm sure of just the opposite here -- the room was definitely full of very smart people that know what they are doing.  Anyhow, feel free to download my presentation and code from http://www.WilsonDotNet.com/Downloads/IntroORMapping.aspx -- the key to me is to compare the code and procs in the Standard project with the lack of similar code in the ORMapper project, which is far more important than the slides.

5 Comments

  • Hi Paul,



    It was a great presentation. I was really surprised to find out that it was 9PM when the question answer session ended. Time really flew by very quickly. Obviously, there were many who enjoyed the O/R mapping concepts.



    Rama Krishna

  • Paul,



    You should really considering doing a podcast of such a talk. I think people hearing an expert such as yourself dispelling the O/R mapping myths would be a boon to all of us who are trying to convince our organizations that OR mapping is a good thing and not some new toy for OO dreamers.

  • Despite your protests to the contrary, it was a really great talk. The combination of interesting topic and impassioned speaker made for an interesting evening.



    Your points on measured performance with O/R mapping were especially interesting. This is the kind of information that potential O/R users are really looking for.

  • One thing that would greatly help the O/R Mapping cause would be to stop pushing the "write fewer stored procedures" point of view.



    ORM can be very effective when used in conjunction with stored procedures, and stored procedures are all about attack surface area.



    In order to expose client_order to my end user with most ORM systems, I must allow the process performing the ORM to have full access to the client_order table. And yes, it really still is most ORM (disappointingly, since I can remember having this same discussion with a manager about three years ago and coming to the same eventual conclusion).



    What really is needed is CRUD stored procedures that can take an opaque token indicating an authenticated user, so that the database can prevent any user that doesn't have an opaque token from seeing any client_order, and so that the database can limit client_order to only those that a specific token ought to have access to (and write audit logs if there is an attempt outside the security rules).



    In this way, even if the process containing the ORM is compromised, the database remains resiliant against attacks, and is not, itself compromised.



    An ORM system that both supports stored procedures and supports the factory pattern is capable of providing this feature. There are a handful of ORM's that do, in fact, provide this level of support.



    ORM in and of itself is a tool. All tools have their uses. In a secure code base, an ORM that does not support stored procedures is a serious liability.



    I would like to see more ORM's gain more support for common secure database practices, such as stored procedures (in general) and stored procedures with opaque tokens (in particular).



    I would also like to see more ORM's focus more on the modelling relationships side of things and less on the "you'll never have to write a line of SQL again" aspect -- I think that you'll have a lot better luck pushing forward that way.

  • Hi Dave:



    I strongly agree that O/RMs should support stored procs -- and by the way mine does. :) I don't however think that a stored proc is necessary for security -- its very easy to use an application role and only give it the proper permissions so that other users do not have those abilities. But nonetheless, I do understand the concern, and even if its not there are still times when a stored proc is best, if not required, so I do agree stored procs should be supported.



    I guess my opinion is that using an O/RM with stored procs in all cases, as opposed to just a few special cases, isn't accomplishing anywhere near as much. Its not as flexible at all, nor is nicely loosely coupled to promote better maintenance and code simplification. And of course its not as portable, although I will grant you that many people don't care about that one -- but the others are a huge deal to me, especially flexibility -- the ability to filter and sort on anything, with paging even.



    Thanks, Paul Wilson

Comments have been disabled for this content.