Hacker News new | ask | show | jobs
by akmiller 4796 days ago
"At some point you'll have to parse out result and build an object graph anyway"

This type of thinking has to stop! Sure, some times it may be necessary to extract data from SQL and turn it into some type of object. However, most of the time it's enough just to get the data and work with the data directly.
2 comments
macspoofing 4796 days ago
Be serious. I made this argument in another thread: I don't believe for a second that it's good practice to just work with SQL directly in your business logic. You don't want to litter your code with serialization logic. You don't want litter your code with constraint checking everytime you make a query. Even if you don't use an official ORM framework, you will write an abstraction layer that will duplicate some of the ORM functionality.

I worked with redis extensively, and i got to the point where it was too dangerous to simply assume that none of the other guys on the team (or me) wouldn't put some garbage data in a field because from redis' perspective, every key looks the same and every value is as good as the next. We rolled our own abstraction layer, in which keys and values were wrapped in domain specific objects.

Programming languages, and databases are too general to be useful. If you don't 'constrain' them to your domain, you're going to get destroyed once your product or team scales to a certain size.

link
akmiller 4796 days ago
Not converting data into object graphs does not necessitate working with SQL in your domain model. I'm currently working on an application right now which favors simple data structures (hashes, arrays) over custom entities. It favors a business layer that operates on those data structures over composing dozens of "Model" based classes. That does not mean that persistence logic is littered within my domain.
link
rmrfrmrf 4796 days ago
* grabs OO sword and shield and prepares for battle * .
link
akmiller 4796 days ago
Ha! I have no problem with OO based programming. I do have a problem with OO based solutions for every problem. Sometimes it's worth pursuing alternative solutions, whether procedural or functional or a combination of what makes sense.

Not too mention, what many believe as an OO solution is often times far removed from anything remotely OO.

link