4 ms·

Color me "pernicious", but who has ever had a heartwarming experience with ORMs? (I'm not talking about the new breed of micro-ORMs that work very well with CQ

Color me "pernicious", but who has ever had a heartwarming experience with ORMs? (I'm not talking about the new breed of micro-ORMs that work very well with CQRS, but the big old monolithic frameworks). CQRS is a breath of fresh air after years of dealing with ORM overreach and inflexibility.

adambyrtek 9y ago
Well-designed ORMs like SQLAlchemy (and others) are a pleasure to use and make your life so much easier without overreaching and taking over your domain models (in contrast to more opinionated frameworks like Active Record).
michaelbuckbee 9y ago
I think you'd probably include Rails/ActiveRecord in the big old monolithic framework category. So...yeah? I occasionally dip a toe outside to other frameworks and setups and always end up having to keep trying to pull more and more pieces together that I end up getting frustrated and just using Rails. I imagine that everyone's experience is vastly different given the scopes and problems that you're trying to address. I write a lot of little one-off business productivity apps, SAAS backends, etc. YMMV.
Joeri 9y ago
I’ve given up on the entire concept. I’ve used several ORM frameworks, and when interfacing with real world data models (not constructing one from scratch to fit the ORM) I’ve found that writing raw queries and some marshalling code is usually faster and easier to maintain than using the ORM. Plus, the ORM-based models are usually significantly harder to test.
- BigChiefSmokem 9y ago
  Don't forget the overhead that comes with the ORM framework as well. I happen to be of the opinion that ORMs are good for prototyping and very small data models and one-off type projects but not for big leagues, production ready code. For that I would do as you describe and build my own data connector.
- GordonS 9y ago
  ORMs promised to make things simpler, and were considered 'best practice' for a long time. I used them myself for several years, mainly NHinernate and Entity Framework. But on every project I'd spend a lot of time fighting with it, trying to bend it to my will. It's invariably difficult to create mappings with any complexity, such as composite keys. And the queries they generate are usually inefficient monstrosities. I discovered CQRS and micro-ORMs a few years ago, and with few exceptions, I haven't looked back!
crdoconnor 9y ago
Django ORM and SQLAlchemy are both good. They're easy enough to break out of when you want to handcraft more obscure SQL and at the same time they save a massive amount of boilerplate. Some languages - particularly languages with overly rigid and static type systems - are ill suited for building ORMs, so the ORMs in those languages will probably always suck. I think attachment to those languages is what drives some people to think that "ORMs always suck".
maxxxxx 9y ago
For starting up I like ORMs a lot. You just need to know when to stop using it or limiting its use. From my experience using an ORM with a few straight SQL queries when needed works pretty well.
hackerfromthefu 9y ago
Well I've had quite a few heartwarming experiences with ORMs, when used in a specific way. I've found the right ORM a joy to use on small-medium size projects, with a simple data layer using a database driven approach (ie not code-first). The key has been to be able to blow away the ORM code and recreate it at will with no more than a few seconds work (an application of the Factory pattern..). With this approach the ORM got out of the way and didn't cause friction. Then combine the generated classes with functional LINQ/map reduce to enable complex, expressive querying code in the first class language of choice. As this is a controversial topic for some, I want to make a few disclaimers .. - This has worked very well when I've kept the database simple, with logic in the application not the db. (Constraints in Db though). - Extending the DAL domain can be done through partial classes, that are kept when the ORM code is blown away and recreated. - As a bonus of this style, the database is done with standard sql, and could be swapped for another relational one easily. - Upgrade scripts need to be created for database migrations, tooling is available to autogenerate these from snapshots of development databases, and manually extended where needed. - I treated the Db as a Db, not some magic object oriented thing, and handled the (fairly minor) impedance mismatch in application code. - You can always hand optimise some sql if needed, or even call direct bulk update APIs if you need top performance in specific parts of the application .. I use the ORM was used as a unit of work pattern so it's possible to do other units of work in other data access technologies, when optimising for something other than developer ease. On the other hand I've seen configuration heavy ORMs suck a lot of time and cause heartache .. Of course, ymmv, but using the approach outline above it has literally been a breeze, and a heartwarming experience for me and other devs when they get used to it, on dozens of projects done this way.

adambyrtek 9y ago

Well-designed ORMs like SQLAlchemy (and others) are a pleasure to use and make your life so much easier without overreaching and taking over your domain models (in contrast to more opinionated frameworks like Active Record).

michaelbuckbee 9y ago

I think you'd probably include Rails/ActiveRecord in the big old monolithic framework category. So...yeah? I occasionally dip a toe outside to other frameworks and setups and always end up having to keep trying to pull more and more pieces together that I end up getting frustrated and just using Rails. I imagine that everyone's experience is vastly different given the scopes and problems that you're trying to address. I write a lot of little one-off business productivity apps, SAAS backends, etc. YMMV.

Joeri 9y ago

I’ve given up on the entire concept. I’ve used several ORM frameworks, and when interfacing with real world data models (not constructing one from scratch to fit the ORM) I’ve found that writing raw queries and some marshalling code is usually faster and easier to maintain than using the ORM. Plus, the ORM-based models are usually significantly harder to test.

BigChiefSmokem 9y ago
Don't forget the overhead that comes with the ORM framework as well. I happen to be of the opinion that ORMs are good for prototyping and very small data models and one-off type projects but not for big leagues, production ready code. For that I would do as you describe and build my own data connector.
GordonS 9y ago
ORMs promised to make things simpler, and were considered 'best practice' for a long time. I used them myself for several years, mainly NHinernate and Entity Framework. But on every project I'd spend a lot of time fighting with it, trying to bend it to my will. It's invariably difficult to create mappings with any complexity, such as composite keys. And the queries they generate are usually inefficient monstrosities. I discovered CQRS and micro-ORMs a few years ago, and with few exceptions, I haven't looked back!

crdoconnor 9y ago

Django ORM and SQLAlchemy are both good. They're easy enough to break out of when you want to handcraft more obscure SQL and at the same time they save a massive amount of boilerplate. Some languages - particularly languages with overly rigid and static type systems - are ill suited for building ORMs, so the ORMs in those languages will probably always suck. I think attachment to those languages is what drives some people to think that "ORMs always suck".

maxxxxx 9y ago

For starting up I like ORMs a lot. You just need to know when to stop using it or limiting its use. From my experience using an ORM with a few straight SQL queries when needed works pretty well.

hackerfromthefu 9y ago

Well I've had quite a few heartwarming experiences with ORMs, when used in a specific way. I've found the right ORM a joy to use on small-medium size projects, with a simple data layer using a database driven approach (ie not code-first). The key has been to be able to blow away the ORM code and recreate it at will with no more than a few seconds work (an application of the Factory pattern..). With this approach the ORM got out of the way and didn't cause friction. Then combine the generated classes with functional LINQ/map reduce to enable complex, expressive querying code in the first class language of choice. As this is a controversial topic for some, I want to make a few disclaimers .. - This has worked very well when I've kept the database simple, with logic in the application not the db. (Constraints in Db though). - Extending the DAL domain can be done through partial classes, that are kept when the ORM code is blown away and recreated. - As a bonus of this style, the database is done with standard sql, and could be swapped for another relational one easily. - Upgrade scripts need to be created for database migrations, tooling is available to autogenerate these from snapshots of development databases, and manually extended where needed. - I treated the Db as a Db, not some magic object oriented thing, and handled the (fairly minor) impedance mismatch in application code. - You can always hand optimise some sql if needed, or even call direct bulk update APIs if you need top performance in specific parts of the application .. I use the ORM was used as a unit of work pattern so it's possible to do other units of work in other data access technologies, when optimising for something other than developer ease. On the other hand I've seen configuration heavy ORMs suck a lot of time and cause heartache .. Of course, ymmv, but using the approach outline above it has literally been a breeze, and a heartwarming experience for me and other devs when they get used to it, on dozens of projects done this way.