Data Access Objects old fashioned? [closed]

Question

A couple of weeks ago I delivered some work for a university project. After a code review with some teachers I got some snarky remarks about the fact that I was (still) using Data Access Objects. The teacher in question who said this mentions the use of DAO's in his classes and always says something along the lines of "Back then we always used DAO's". He's a big fan of Object Relational Mapping, which I also think is a great tool. When I was talking about this with some of my fellow students, they also mentioned that they prefer the use of ORM, which I can understand.

It did make me wonder though, is using DAO's really so old fashioned? I know that at my work DAO's are still being used, but this is due to the fact that some of the code is rather old and therefor can't be coupled with ORM. We also do use ORM at my work.

Trying to find some more information on Google or Stack Exchange sites didn't really enlighten me.

Should I step away from the use of DAO's and only start implementing ORM? I just feel that ORM's can be a bit overkill for some simple projects. I'd love to hear your opinions (or facts) about this.

Answer 1

It is more "fashionable" but that doesn't mean it isn't more functional. There are some developers who have only interacted with data storage using an ORM.

Determine why you think an ORM is "over-kill" for a simple project. Do a little research and find out why they were created. Does it only make larger/more complex tasks easier or does it make basic/repetitive/mundane tasks easier? Does it require the inclusion of more code that you don't really need? Does it require more lines of code or does it obscure what is really happening so much that you can't trouble-shoot it? You may find that your skill set with one method is more fluent than another.

I think formatting code is similar. Once you get familiar and fluent with something (e.g. code indentation) it becomes more difficult to not do it. Working with legacy code can sometimes hinder gaining fluency with new technologies.

Answer 2

I think it depends on the project. Both have their place.

DAOs will give you greater level of control and can do things an ORM cannot do. TVFs in MS SQL Server for example are not available in EF. If you need to work across mulitple databases in one stored procedure, that cannot be done in cleanly in EF. So for low level control of your T-SQL, DAOs have their place.

On the other hand, for basic/straight-forward data access I would use an ORM. Its less time consuming for me to do so, so less cost to my client. It also displays the database schema and relationships in a clean easy to pick up and understand manner. This minimises time for other developers to pick up the project and understand it