
DAO Is yet Another OOP Shame - filfreire
http://www.yegor256.com/2017/12/05/data-access-object.html
======
scarface74
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.

------
prepend
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.

~~~
Finnucane
>In the end, Im not sure what the article complains about.

It seems that the way an ORM abstracts talking to the database is not the way
he would like it to happen. So he makes his own custom abstractions that
involve sending raw sql strings instead. That's better?

~~~
scarface74
I am always concerned when I see developers think they are their problem is
it's own special snowflake that they need to write something custom to handle
cross cutting concerns like configuration, database access, logging, security,
etc.

It makes it harder to ramp people up when you aren't using a popular package
(preferably open source with an agreeable license) and there is usually only
that one person in the company that understand it's weird quirks instead of
being able to Google for a solution to a problem.

~~~
Finnucane
I think is why a system like SQLAlchemy in Python is nice--if you really need
to build something up from lower-level parts, you can, while still staying in
the framework.

------
ncphillips
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.

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

Do you mind expanding on this a little bit? I am very confused. A "data
structure" is an implementation of an abstract data type
([https://en.wikipedia.org/wiki/Data_structure](https://en.wikipedia.org/wiki/Data_structure)).
A "class" is also an implementation of abstract data type (from this book
[https://www.amazon.ca/Object-Oriented-Software-
Construction-...](https://www.amazon.ca/Object-Oriented-Software-Construction-
Book-CD-ROM/dp/0136291554) page 165).

I am not sure how you can have a data structure Book without any operations.
Even if it were a C struct, accessing a field would consist an operation
around that data structure.

------
partisan
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.

~~~
HelloNurse
I'm quite happy designing (in C# or Java) DAO-like classes with methods
corresponding to meaningful queries and transactions (the specific and often
complex operations needed by the application, _never_ "save an object" or
"find all").

I encapsulate all database access, including dealing with connections and
transactions; I have a single point of authority regarding where data come
from and how I call update operations; and all objects coming in or out of the
DAO are free of database dependencies (no persistence nonsense).

DAO/DTO designs, in my experience, tend to go bad when there's inappropriate
repetition and complication: slightly different validation in different
operations, validation in client code, multiple similar queries without
consolidation, unwarranted different classes used in different cases,
translation between back-end dumb containers of data and marginally different
front-end dumb containers of data instead of thinking about a proper data
structure, and so on.

------
Psilidae
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.

------
AllegedAlec
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".

------
anilmujagic
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/](https://www.coindesk.com/understanding-dao-hack-journalists/)

