|
|
|
|
|
by nodamage
27 days ago
|
|
Which ORMs are you basing this comment on exactly? (1) and (3) are not really problems with an ORM that gets out of your way and lets you drop down to raw SQL when necessary, but still helps you hydrate result rows back to objects (and still provides the associated features I mentioned previously). (2) and (5) can be interpreted as "your ORM does not absolve you from knowing SQL". I've never personally run into a situation where doing (4) or (6) were desirable. > The correct answer is to use a query builder + database model, enabling most queries to be written with some degree of type-safety, and minimizing the abstraction from SQL itself, and toss out the rest of the featureset If you work on projects where a full featured ORM can be replaced by a simple query builder then cool, but the rest of the feature set is really useful for the projects I work on so why would I toss them out? |
|