Hacker News Reader

> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for

I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to change. For the joy of a quicker startup the entire project moves slower.

ORMs have their place, but in the majority of the systems I've seen they were unnecessary, and in broad terms don't provide any particular productivity advantage over using "dumb" SQL-based mapping solutions (a la Dapper [https://github.com/StackExchange/Dapper]), that preserve the power of SQL.

About 17 years ago, I wrote a GUI-based code generator that allows me to generate the boilerplate JDBC cruft from SQL statements, with several options for common scenarios. The code it generates is extensible and provides helpers for extending.

To this day, I haven't found anything (including ORMs, Spring support, etc.) easier to use, more flexible, or more sensible.

Is it closed source? I am in search for something like this. I consider this as Naked Object approach.

Unfortunately, it is closed and wired into an overall framework I crafted, so has some dependencies there.

If I were to write it today, I'd be more conscious of limiting dependencies and generally designing with open-sourcing in mind.

I recently wrote one for C# / MSSQL. I've been using EF on side projects, but work was concerned with it, so I just wrote a CRUD sproc / Entity / Repository / Service / DTO generator. Connect to a database and select the tables you want to build for, and done. 5 layers of abstraction in under a second. It gets me to about 95% of what I need and I custom build the special circumstance stuff from the generated objects. It creates the "if exists / drop" stuff, exception handling and comments w/ dates in the sprocs that reference the objects in C#, and vice versa, what table was referenced, proper [Key] and [MaxLength] attributes, etc. Puts them in their proper folders for git too. It does exactly what I would have done had I done it manually.

Works great with no ORM abstraction and it was fun to write.

Yeah, very similar--with one primary enhancement: That is, I initially started generating objects-per-table, but found that it was a little limiting for a lot of use-cases I encountered. In particular, it didn't cover joins very well--particularly for queries that fed list views.

So, I expanded into supporting raw SQL SELECT queries that can include joins, which I parse and combine with DB metadata. I then generate the DTOs from there. So, a single DTO can have properties mapped to different tables, which I found much less redundant/limiting than entity-per-table designs.

In addition to the SELECT code, I can use simple checkboxes to also generate INSERT/DELETE/UPDATE/UPSERT code, which map the DTOs back to the underlying tables. It recognizes keys and includes multiple-table writes in a single transaction, etc. In addition to the DTOs and the DAO layer, it can also optionally generate a service interface.

Of the utilities I've written over the years, it is the one that most stands out as having paid me back incalculably.

I’m actually quite fond of SQL, but I disagree that ORMs are not a productivity boost. My experience is in Rails and I think ActiveRecord is a pretty clear win for simple queries. That being said, it is pretty common for less experienced developers to not understand what the ORM is actually doing.

On any project of sufficient size there will be fairly advanced reporting functionality that you generally will not be able to do using ORM so you will end up with a mix of ORM and direct SQL. Also ORM forces you to the lowest common denominator for supported RDBMs I generally do not want to be limited to the SQLite features if I am running PostgreSQL

I did qualify my statement with “for simple queries”.

For more complicated queries, a pattern I have become quite fond of is making database views and then using them as the backing table for an ORM model. In Rails, at least, this gives you the best of both worlds.

Yep that works well for many use cases

Using PostgreSql, I tend now to directly generate query result in json.

It implies an architecture model where you put the business logic and type safety in the RDBMS.

It reduces the number of layers for a lot of functionalities.

How does version control work for an architecture like this?

In my experience, migration scripts that include modifications to output JSON (as ALTER TABLE statements) are always tracked and programmed to be auto-executed on each version update.

If your application mostly reads from the DB then don't use a ORM. I think ORMs shine when you need to save/update a domain model to a relational DB. In the CQRS world, a fairly typical choice when using a relational DB is to use a ORM for the write side and raw SQL for the read side.

> People think writing DTOs is challenging

I don't think this is true. Writing these objects isn't difficult, it's tedious and repetitive. That's why people keep trying to automate it!

The problem is that you can't quite automate it smoothly, because SQL doesn't work like objects. You avoid this interface issue by taking the hit for the tedious-and-repetitive stuff directly (and I agree that's often the right choice) - but that doesn't dissolve the problem.

I do things "the hard way".

I agree, except that I would argue it’s often the easier way. If I had to give a one sentence answer to the original question, it would be, “Front-end [web] development is so unstable because people introduce so much accidental complexity.”

For example, while I don’t disagree with Meredydd that there can be awkward mismatches between the layers he described, I also think several of those layers only exist if you presuppose an object model in your programming languages. Arguments about object-relational mismatch have been made as a criticism of OO for far longer than we’ve been building substantial front-ends for web apps.

If instead you stay closer to the real data, your architecture reduces to the more traditional persistence and presentation layers. Since you’re on the web you have a distributed system so you also need a protocol for the remote communication between those layers. However, there aren’t any inherent mismatches in that combination, any more than there are if you build native applications or distributed systems using something other than web technologies.

I think a lot of the disconnect can go further away as JSON data types (regardless of actual serialization such as BSON etc) and use are more well supported at the database layer. When I did more C#, and Entity Framework came out, I'd add an XML column to most of my tables, as well as a base class wrapper for my own use... that allowed by to write extension properties that wrapped around XML nodes under the covers. So I could extend with extra properties for things that didn't need to be queried on.

It worked pretty well, of course I actually started doing it because getting schema changes at my workplace was a painful endeavor.

I agree that a lot of the disconnect is induced by developers. It's also part of why I'm a pretty big proponent of a JS UI talking to a service written in JS. It allows for a lot less cognitive adjustment. I remember doing HTML/CSS/JS with Flash/Flex, with .Net, T-SQL, and VB6 in one workplace regularly. I swear every time I had to change from one to another, I was typing the wrong way for a good 15-20 minutes... answering questions at times took 2 minutes just to shake my brain out of whatever I was working in.

I started using less stored procedure code and the DB more as dumb storage, and embraced node pretty early on. Even if it is a "lesser" language, there's something to be said for one language to rule them all. (I do like modern JS though.)

Have you ever looked into Clojure/ClojureScript? The Clojure ecosystem seems to favor your approach. They embrace the dynamic nature of this kind of programming, are data-oriented, shun ORMs, and generally have solid principles (in my opinion). I found it was well worth working through the (somewhat steep) onboarding curve.

> The Clojure ecosystem seems to favor your approach. They embrace the dynamic nature of this kind of programming, are data-oriented, shun ORMs, and generally have solid principles (in my opinion).

I've recently started my Clojure journey (< 1 month in!), after stumbling across aphyr's very interesting work, and it is being driven entirely by this line of thought. It's taken me a long time, at least a decade, of moving deeper and deeper in to web development to start to really appreciate this perspective but it _feels_ like The Right Way at this point in my career. I'm hoping to, at the very least, be able to take those lessons from Clojure and apply them to the areas of my professional life.

I have, but haven't had the opportunity to really dig in. :-) . It's on my list... along with Go and Rust as things I want to learn.

> WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries?

I am getting into frontend for a hobby project after spending a few years doing ML and applied stats, and I am currently asking myself this question. If your db interaction is simple, a query is almost as easy to write and maintain as an interaction with an ORM, and is significantly more flexible. If it is something more sophisticated, then your ORM quickly becomes more of a hindrance than a help. What am I missing here? Where is the virtue of an ORM beyond not having to use SQL?

In more static languages, you generally need to convert from the DB types to the Native types to your language. This means a lot of code (more than boilerplate ORMs) and prone to a lot of mistakes.

Some tooling that generates it for you helps a lot in some cases. I can see the appeal, but not in a dynamic language environment where there is less disconnect.