4 ms·
Usually the recommendation and the simpler approach is quite the opposite: You can't version control, deploy and generally handle database function as easily as
by kissgyorgy 7y ago
Usually the recommendation and the simpler approach is quite the opposite: You can't version control, deploy and generally handle database function as easily as a piece of code. My experience is that nowadays more and more code is pushed to the ORM or database handling code level because it greatly simplifies everything.
- JohnBooty 7y agoThe author's not advocating anything as drastic as abandoning the application layer entirely, of course. These aren't mutually exclusive approaches. You can use an ORM like ActiveRecord to manage migrations and move functionality down to the database layer when reasonable to do so.
- claytongulick 7y agoORM's have improved considerably over the years, but I've always been a bit hesitant to use them. I've seen a lot of developers begin to believe in the abstraction, and forget the underlying access. This has caused performance problems with increased round trips to the server, non-obvious indexing strategy issues, and code tightly coupled to the ORM rather than the data. I get especially suspicious with framework-type ORMs that can cause a massive rewrite between major versions. It's costly, time consuming, and doesn't provide any application benefit, it's only new forms of abstraction. ORMs are seductive, because a lot of these issues aren't obvious when you first start using them. The marketing is usually pretty compelling. Unfortunately, by the time you start to run into issues I've described, it's normally too late to change paths.