2 ms·

>>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also you

by dhd415 9y ago

>>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM.<< Whether you use an ORM or not, your data layer can (and generally should) be designed to present a logical data model that may differ from your physical model. While some ORMs offer easy hooks for the addition of caching and analytics, the same is true for a well-designed data layer. I've also seen naive ORM implementations of those kinds of features cause more trouble than they were worth. >>Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.<< While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.

gnaritas 9y ago
> While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. No, lack of thought in using the tools isn't the same as the tool forcing you to do it. Put the complex and efficient query into a view and map the view with the ORM, problem solved and SQL used appropriately and the ORM used appropriately.
wdewind 9y ago
You completely disregarded all of the organizational and communicative benefits I mentioned in favor of performance. Sometimes that will be the right choice to make, sometimes (I'd argue frequently) it will not. > A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. This is not true, unless using the data layer instead of ORM allows you to structure your data differently. In which case, sure.

by dhd415 9y ago

gnaritas 9y ago

> While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. No, lack of thought in using the tools isn't the same as the tool forcing you to do it. Put the complex and efficient query into a view and map the view with the ORM, problem solved and SQL used appropriately and the ORM used appropriately.

wdewind 9y ago

You completely disregarded all of the organizational and communicative benefits I mentioned in favor of performance. Sometimes that will be the right choice to make, sometimes (I'd argue frequently) it will not. > A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. This is not true, unless using the data layer instead of ORM allows you to structure your data differently. In which case, sure.