Persistence Patterns in MSDN Magazine

Posted by Jeremy Miller on March 24, 2009

The April edition of MSDN Magazine includes my latest article for the “Patterns in Practice” column.  This time around I tackled very basic Persistence Patterns.  My goal in this article was merely to introduce and explain some of the core concepts that come up in object persistence.  I don’t discuss old-fashioned procedural Data Access Layer techniques because I feel that those are very well understood (and obsolescent at best).  In this pass, I covered:

Mapping Objects to Databases

Active Record

Data Mapper

Using a Repository

Identity Map

Lazy And Eager Loading

Virtual Proxy Pattern 

An experienced ALT.NET ish developer will notice some glaring omissions in this article.  It looks like I’m ditching the article that I was foundering on and writing a follow up to Persistence Patterns that talks more about architectural ramifications of persistence, some discussion of what your Repository should actually look like, and that little Unit of Work pattern. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.orasissoftware.com Adnan

    Jeremy,

    Thanks for an informative article. But like some other readers, I failed to see the reason why my Objects must map to Database Tables, and hence why an ORM implementation must be used.

    I can write a perfectly well Object Oriented Data Access layer, if I have built my Application on the MVC or MVP design pattern. All I have to write is a Data Mapper Layer that maps the model objects to my database. I do not see the need to use an ORM for that; a simple ADO.NET layer that executes queries and maps them to objects should suffice.

    If you want to see an implementation of that pattern and a tool that helps you build the Data Mapper class. I strongly suggest you to evaluate it from http://www.orasissoftware.com and see how easy it is to build Data Access Layers.

  • Bill Campbell

    Hi Jeremy,

    Thanks for another great article. Although I’ve been in this business for way too many years, I always enjoy discussions like this that start dirt simple. Thanks for taking the time to detail all this information for the community! Looking forward to the next article. I’m hoping for a little more clarity on the relationships between the NH Objects (like Address in your example) and Repository objects. I don’t know if you are going to talk about that in your next article. Are the repository objects (which are usually a list or a collection of those objects) totally separate from the lists that are created in the NH Objs and how is the data being moved between these – or maybe I am just really confused. :)

    Anyhow – thanks for all the great info!!

  • AStorm

    I have an architecture issues/question. I am using the MVP pattern in our WinForms application, it is working out well as we begin but I am wondering if I can get some input from you all on object management. I believe that I am loading too many large objects up front as my memory usage grows quite rapidly is there a pattern or something less formal that others have used to load objects in a more JIT technique so the GUI stays responsive but not over bloated.

  • http://addwatch.wordpress.com José Filipe

    Hi Jeremy, great article.

    I’ve been working with my team in a big project using NHibernate, and the design patterns explained in the article really gave me another perspective and made me question some things that we’re doing until now.. and that would be simply enough for the reading worth! :)

    There are some questions not addressed by you in this article, actually, that I’d like to question: the lazy/eager load discussionis quite understandable but, when you put them over the wire, I think that things become a lit bit more confusing. We’re using “raw” web services to transport our objects through client and server, and the lazy loading objects’ properties have to be iterated in server side so the object is sent “complete”. My doubt is: is there any pattern or good practice in this field? WCF would help with something? We also have some problems with circular references, but that’s another point..

    Also there are some future points that you list in the article that look very interesting (probably because I already had doubts about it), specially the one about “a single generic repository versus specific”. Would you have some links that I could look around?

    Thank you.

  • http://weblogs.asp.net/fbouma Frans Bouma

    “Then again, from the comments I’ve seen you make any time the subject of PI comes up, I’m not convinced that you yourself truly understand my point of view at all.”
    I think you’re mistaken on that. I’m not talking about code at all, I’m talking about the reason behind the existence of an entity class and a table definition and why they can be coupled through o/r mapping. Please read my essay in Nilsson’s ADDDP book, you’ll see I’m not focussed on code at all.

    PI is another subject. If you focus at code after you’ve made the decision to project entity definition X onto code, it’s up to you to develop that class for entity definition X and that can be done in various ways. I’m not convinced there’s such a thing as PI, and others are, but that’s not important for the point I was trying to make.

    I think it’s a mistake to explain what persistence is all about when you start with code, as it’s the same as you want to explain it when you start with a table definition and explain SQL: it’s one step too far, the real source of it all is not a class and not a table, but the entity definition, which is abstract.

    If you start with focussing on code constructs (or table definitions and sql queries, the same thing), the theory behind WHY these are there misses. I understand that that is a big chunk to start with and most ‘developers’ simply want to dig in and type away but without understanding the reasoning behind why class X is mapped onto table T and not table U (so they understand HOW, but not WHY), they’ll never fully grasp why they 1) have to go through the learning curve, 2) why their way of working was not correct and 3) can’t maintain their own work as they don’t understand why their work is the way it is.

    Jeremy, I’m not here to argue with you for the sake of arguing with you nor bash your effort, on the contrary: I admire what you’ve written and I find it great that you invested your spare time to write a large article. From experience, I know that by starting with the how and not the why in this particular field (persistence), you probably won’t reach the goal you might have set. You might not find my experience in this particularly helpful, but trust me, after helping thousands and thousands of people in this particular field, I know a bit about what helps and what not. ;) I wished it was as simple as explaining the patterns and it would be enough. For some it is, but for others it’s not. The sad thing? For those people, the knowledge they lack to understand it in full is rarely explained, as it’s stuffed away in ‘dull’ books like the ones about NIAM/ORM or old papers by Chen.

    Looking forward to your next article, Jeremy. Again, kudo’s to you for your effort, keep up the good work :)

  • Jeremy

    Frans,

    @Frans,

    I’m hitting a little bit of that discussion in the next article — which I’m sure you’ll disagree with completely (I’m spending a lot of discussion on the design *goals* from using a PI persistence solution). Then again, from the comments I’ve seen you make any time the subject of PI comes up, I’m not convinced that you yourself truly understand my point of view at all.

    I used the Address sample because it’s dirt simple. Let’s get a very basic example of Data Mapper and Active Record going first for the people who only know how to use DataSet’s and procedural code before we dive into why or why not you need Persistence Ignorance, value objects, public setters may be evil, and strategies for mapping inheritance hierarchies?

    Come back and argue with me after the next article.

  • http://weblogs.asp.net/fbouma Frans Bouma

    What I find a missed chance in your article is that it lacks an explanation why mapping the Address class to the Address table is legit, why it works and why that’s done and why it’s not mapped to table ABC instead. Perhaps that wasn’t in the scope of the article, however IMHO it would have made things more clear because it would explain why these patterns were necessary and also why they work, which is IMHO essential info.

    I’ve stressed this a number of times and I get laughed at about this, but domain classes don’t fall out of the sky and neither do the tables in the db: they’re the projection result of an abstract entity onto code resp. relational model, and because the class and table share the same source, you can map class onto table (or table onto class, whatever rocks your boat) because they represent the same thing: they give the same meaning to the DATA contained in them.

    I missed that in your article, but again, it might have been out of the scope of it.