Our great sponsors
-
Slick
Slick (Scala Language Integrated Connection Kit) is a modern database query and access library for Scala (by slick)
-
Dapper.SimpleCRUD
Who wants to write basic read/insert/update/delete statements? SimpleCRUD provides simple CRUD helpers for Dapper.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
sql-template-tag
ES2015 tagged template string for preparing SQL statements, works with `pg`, `mysql`, and `sqlite`
-
TypeORM
ORM for TypeScript and JavaScript. Supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, Oracle, SAP Hana, WebSQL databases. Works in NodeJS, Browser, Ionic, Cordova and Electron platforms.
Many ORMs introduce a somewhat messy, complicated abstraction layer that doesn't actually get you the desired benefit in statically typed languages - compile time safety. Mainly because most languages do not have sufficiently powerful type systems.
Exceptions are libraries like persist [1] for Haskell, Slick [2] for Scala, and - with caveats - Diesel [3] for Rust.
But: manually mapping between the database domain and your domain objects is also a messy, error prone process that is wasted effort.
My preferred solution is to stick with simple ORMs that just do simple mapping and provide a convenient query builder, without any heavy magic in the objects or any sort of automatic relationship logic (automatic fetching of joins, ...).
[1] https://hackage.haskell.org/package/persistent
[2] http://scala-slick.org/
[3] http://diesel.rs/
I use dapper with a plugin called dapper.simplecrud (https://github.com/ericdc1/Dapper.SimpleCRUD). This already helps to reduce the need to write simple but error-prone SQL code quite a lot. When doing SQL operations more complicated than a simple crud, I resort to raw SQL or stored procedure.
> People always seem to ignore the third option: using an ORM that embraces SQL!
I had a similar revelation several years ago, based on the distinctions between a "domain model" and "persistence model" described by Mehdi Khalili, resulting in Atlas for PHP: http://atlasphp.io
Does this correspond to the data mapper pattern? Seems like people mostly object to active record orm variants.
https://typeorm.io/#/active-record-data-mapper/what-is-the-d...
Considered it, but I think that there are advantage in programmatically construct the query (see for example knex modify). Directly write down SQL or use template with sql make it harder. The only problem with knex is that it mutate at every operation instead of returning a new instance. I'm experimenting in wrapping it in a lazy monad that return a Fluture (https://github.com/FbN/iodio)
Related posts
- ORMs are nice but they are the wrong abstraction
-
denodb VS denodata - a user suggested alternative
2 projects | 29 Nov 2023
- We migrated to SQL. Our biggest learning? Don't use Prisma
- Comparing database/sql, GORM, sqlx, and sqlc
- Any mid sized / big open source code base in golang that makes use of SQL DBs?