4 ms·

I've developed a deep distrust of ORMs at all. I've found that the majority of simple CRUD projects are better served by just having a DAL with explicitly writt

by aftbit 2y ago

I've developed a deep distrust of ORMs at all. I've found that the majority of simple CRUD projects are better served by just having a DAL with explicitly written (or generated) methods instead.

plandis 2y ago
ORMs have the problem that they are only useful for projects with some complexity but not too much. It’s overkill for small projects and not expressive enough if you’re doing really complicated stuff. Even if you do have a good use case for an ORM currently as your requirements grow it gets harder to hack stuff on that you need.
9rx 2y ago
> just having a DAL with explicitly written (or generated) methods instead. That's a bit orthogonal. Even if you use an ORM library, you'd be remiss to not put it behind a DAL. But from your DAL if you emit/accept objects of your own transformation: Congratulations, you've just invented an ORM. You can emit/accept relations, which is quite justifiable, but even then you are bound to have to map it to objects at some point. e.g. interfacing with third-parties that require objects. There is really no escaping ORM in any reasonably complex real-world application.
- necovek 2y ago
  "Objects" implies a few more properties than a simple data carrying container: while it might be expressed in a particular language using classes/objects, you really don't care about any of the "object"-like features other than the ability for it to contain attributes. Generally, you can go a long way with simple, combined types which are closer to maps/hashes/dicts than to "objects" other than syntax (.attr vs ["attr"]). And really, that would be my preference: combine a query builder (some ORMs have great ones too) with native types representing the data read from the database.
  - 9rx 2y ago
    > "Objects" implies a few more properties than a simple data carrying container: Agreed. Of course, strictly speaking, a relation is specifically a set of tuples. But if you are working with a SQL database, which has been implied, you are already long past that idea, so it is understood that we're speaking of the concept somewhat more loosely. An instance of a class with a set of basic properties nestled in an array would still reasonably be considered a relation as it pertains to this discussion, as far as I am concerned, and seemingly you too. Fair to say you haven't meaningfully changed the semantics of the data in that. But that doesn't mean you won't need to map to objects. You almost certainly will at some point in a reasonably complex application, even if only to interface with third-parties.

by aftbit 2y ago

I've developed a deep distrust of ORMs at all. I've found that the majority of simple CRUD projects are better served by just having a DAL with explicitly written (or generated) methods instead.

plandis 2y ago

ORMs have the problem that they are only useful for projects with some complexity but not too much. It’s overkill for small projects and not expressive enough if you’re doing really complicated stuff. Even if you do have a good use case for an ORM currently as your requirements grow it gets harder to hack stuff on that you need.

9rx 2y ago

> just having a DAL with explicitly written (or generated) methods instead. That's a bit orthogonal. Even if you use an ORM library, you'd be remiss to not put it behind a DAL. But from your DAL if you emit/accept objects of your own transformation: Congratulations, you've just invented an ORM. You can emit/accept relations, which is quite justifiable, but even then you are bound to have to map it to objects at some point. e.g. interfacing with third-parties that require objects. There is really no escaping ORM in any reasonably complex real-world application.

necovek 2y ago
"Objects" implies a few more properties than a simple data carrying container: while it might be expressed in a particular language using classes/objects, you really don't care about any of the "object"-like features other than the ability for it to contain attributes. Generally, you can go a long way with simple, combined types which are closer to maps/hashes/dicts than to "objects" other than syntax (.attr vs ["attr"]). And really, that would be my preference: combine a query builder (some ORMs have great ones too) with native types representing the data read from the database.
- 9rx 2y ago
  > "Objects" implies a few more properties than a simple data carrying container: Agreed. Of course, strictly speaking, a relation is specifically a set of tuples. But if you are working with a SQL database, which has been implied, you are already long past that idea, so it is understood that we're speaking of the concept somewhat more loosely. An instance of a class with a set of basic properties nestled in an array would still reasonably be considered a relation as it pertains to this discussion, as far as I am concerned, and seemingly you too. Fair to say you haven't meaningfully changed the semantics of the data in that. But that doesn't mean you won't need to map to objects. You almost certainly will at some point in a reasonably complex application, even if only to interface with third-parties.