DAO Is yet Another OOP Shame

I'm a Domain Driven Design True Believer. But sometimes we all write stuff that's just CRUD and transaction scripts (in DDD parlance not SQL)

I also read the guys arguments against how ORMs are still SQL like, I contend that's caused by most (non functional?) languages not treating querying against collections as first class citizens.

I'm a big fan of C# and my favorite feature is Linq. With Linq you can query any data source using native type safe C# syntax, pass Linq expressions around and they will get translated on the fly to a query language that the source understands. You can send your Linq expression to sql Server, Mongo etc in production and mock out your source in your unit tests to use Lists and still test your queries.

This seems to be an argument for or against simplicity. DAOs are just one pretty useful way to abstract database access. In the beginning they are almost always too much for what you need as far as data access, but provide a consistent way to access persisted data. You don’t need them, but they are a safeguard against the future where it gets more complex and you don’t want to refactor a bunch of code.

There’s also multiple ways to implement and having a DAO that spits out transfer objects or value objects that aren’t connected to the db is perfectly fine and nice and OOP.

In some situations with complex data structures that require lots of transactions the DAO becomes more important.

In the end, Im not sure what the article complains about. Author shows a simple example as being bad, but doesn’t show an example where it’s needed. And the negative isn’t substantial.

If anything it gets you thinking more like the database system and that could be a pain if you switch off of relational or between systems that represent data differently.

It sounds like one issue is the conflation of Object and Data Structure.

Book, in the presented example, has no behaviour so it is a DataStructure, making it an object introduces needless overhead.

Also, I believe DAOs are intended to be used in more complex cases. For example, I may have a BookSeries class in my database, and I may want it’s instances to have a numberOfBooks property. NumberOfBooks would be a computed value, and it would be the job of the DAO to populate that field when retrieving the BookSeries.

This could go even further, where a class exist that does not map to the database table at all.

Part of the problem comes from having a DAO that mimics your use cases when writing data. That is, adding a new Pipe is a business concern. Here, the author has turned it into a data concern. A business concern should be modeled in the domain layer and persisted through the data access layer. By the time we write to the database, there should be no thought involved. The work has been done and we want to record it. How we do that is purely up to our technical requirements.

Several years ago, I wrote an application using the repository pattern and there were repositories everywhere. But they seemed like a step up from the unstructured chaos of the DAO. It was a bigger mess when all was said and done.

Having struggled through the same issues as the author, I can say that after having learned and applied and DDD, CQRS, and Event Sourcing, I don't see the problem anymore. My concerns are one or more levels above "how do I write to or read from the database?". The database becomes a technical implementation detail and not the cause of crisis in architecting a system. In the past few months, I've used EF as an ORM, EF using just stored procedures, and Dapper, both through a DAO interface. All of these solutions worked and were easy to implement because I was simply recording changes to data, not putting the data at the heart of my logic.

I think I disagree with most of the arguments for this, and I think the author's example of his own "something like DAO" is worse organization. I haven't used "DAO" but from what I understood reading this, it's my preferred pattern of doing database access in which objects are just data, and any database interaction would either return a data object, or take one as a parameter.

From my personal experience, I've found that trying to write database interaction methods on an object seemed to result in (subjectively) messier and harder to maintain code, compared to using functions that take or return objects. To achieve Encapsulation, I'd merge this into functions `static void update(Book b)` or `static Book get()` within the `Book` class.

Though, this preference comes from having been corrupted by functional principles and a strong preference for immutable data objects.

I'm always intensely wary of Yegor's articles. On the one hand, I do agree with him on many points. On the other hand, I couldn't agree less when he makes statements like "objects should be immutable".

Few years ago I'd understand immediately that this is about Data Access Object. But when I saw this title now, my first thought was that it is about the DAO hack [1].

[1] https://www.coindesk.com/understanding-dao-hack-journalists/