By: Cecil R. Woods

Cecil R. Woods — Thu, 17 Jan 2013 18:15:43 +0000

The purpose of a DAO layer is that your application not have any notion of what your persistence mechanism is, or even that things are persisted. It’s a layer of abstraction that gives you flexibility down the road.I’ve relied on this twice in my career. Once was moving a component using Oracle to use a completely different schema (but same object model) in PostgreSQL, and the second was moving from an LDAP directory to an Oracle database (once again, keeping the object model.)Without the DAO abstraction, these projects would have needed substantial work, with a lot of testing. With the DAO pattern, we just wrote new DAO interface implementations, changed the DAOFactory settings, and the app sitting on top of it just plain worked. We didn’t need to test anything other than the queries, because that’s all that changed.If you have a frozen platform and simple ORM using a tool is fulfilling your need, then DAOs might be overkill. But if you ever need to make some major changes, any time spent creating a “redundant” DAO layer will be bought back four or five times.Oh and as for performance, trust me when I say that having to call a DAO that calls an ORM method is not going to make an appreciable difference in your response time when compared to calling the ORM method directly. If you were that worried about performance, you might optimize the SQL yourself, instead of using a mapping tool.

Comments on: Silverlight Data Pager, fake ItemsCount and stored procedures

By: Cecil R. Woods