ORM vs no ORM is an interesting debate that seems to come up quite a bit. I'm in the ORM camp myself, but not because I don't want to know the details of what's happening behind the scenes. In fact, I think learning an ORM when you don't know SQL first is putting a real handicap on yourself.
But despite knowing SQL pretty well, I wouldn't want to build an application without an ORM. There are many pain points without it, but in the interest of not turning this into a full on blog post, I think managing relationships is one of the biggest.
It's just very nice to be able to load an object, and say artist.songs or song.artist or even song.artist.label.
What I'd like to know is what the middle-ground alternatives are, somewhere between having strings of SQL everywhere and using a full-blown ORM.
I get it. Not using an ORM for a front-end app would suck. So, my ORM "Eye of Sauron" will not gaze upon web technology devs.
However, using an ORM when you are building a REST API or a big database, is a mistake in my view. You need to really figure out your objects and normalize them into a one SQL table at a time.
The way I deal with all the cruft SQL needs is to have a bunch of "factory" tools that will generate my SQL schemas and language bindings. Surprisingly, my go-to tool has been Excel of all things. I keep each object in its own sheet, and then use text-generating formulae to spit out Swagger definitions, Go structs, Java Classes, or whatever.
In the case of Go SQL, I stick all this generated stuff into Go functions and then "compile" my SQL statements into "prepared statements". Then I wrap all that stuff with some nice clean function calls like account := getAccount(accountID). I've done the same thing in Java and PHP.
If you are building a backend, then I think you need to pay attention to all the marshalling, unmarshalling, type conversions, and object aggregation that ORMs smooth over for front-end developers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
ORM vs no ORM is an interesting debate that seems to come up quite a bit. I'm in the ORM camp myself, but not because I don't want to know the details of what's happening behind the scenes. In fact, I think learning an ORM when you don't know SQL first is putting a real handicap on yourself.
But despite knowing SQL pretty well, I wouldn't want to build an application without an ORM. There are many pain points without it, but in the interest of not turning this into a full on blog post, I think managing relationships is one of the biggest.
It's just very nice to be able to load an object, and say artist.songs or song.artist or even song.artist.label.
What I'd like to know is what the middle-ground alternatives are, somewhere between having strings of SQL everywhere and using a full-blown ORM.
I get it. Not using an ORM for a front-end app would suck. So, my ORM "Eye of Sauron" will not gaze upon web technology devs.
However, using an ORM when you are building a REST API or a big database, is a mistake in my view. You need to really figure out your objects and normalize them into a one SQL table at a time.
The way I deal with all the cruft SQL needs is to have a bunch of "factory" tools that will generate my SQL schemas and language bindings. Surprisingly, my go-to tool has been Excel of all things. I keep each object in its own sheet, and then use text-generating formulae to spit out Swagger definitions, Go structs, Java Classes, or whatever.
In the case of Go SQL, I stick all this generated stuff into Go functions and then "compile" my SQL statements into "prepared statements". Then I wrap all that stuff with some nice clean function calls like account := getAccount(accountID). I've done the same thing in Java and PHP.
If you are building a backend, then I think you need to pay attention to all the marshalling, unmarshalling, type conversions, and object aggregation that ORMs smooth over for front-end developers.