3 ms·

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. [tangent] That'

by sjs 16y ago

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. [tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple. Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app. ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled. SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice. It all depends what the task is anyway though.

jasonkester 16y ago
Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. That's not unique to ORM. We don't use an ORM at Expat, yet all our objects still have .Load() and .Save() methods. I hope you didn't read my post to mean I advocate hand-writing your CRUD! I think LINQ is a great example of needlessly re-inventing something that wasn't very hard in the first place. Especially since its syntax is so close to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot of trouble?
- heresy 16y ago
  LINQ is far more useful than just as language sugar over SQL. The amount of boilerplate it removes is substantial for anything working with sequences. I actually havent used the SQL backend for it. But since I often work with large collections of heterogenous data outside of a DB, I use it all the time to transform and filter collections in ways that would be very tedious in other languages. Libraries can get you some of the way there, but the language integration is what makes it so painless.
- vyrotek 16y ago
  There's a lot of power and flexibility using a Model with LINQ. The strongly typed nature has saved me many times. When you alter a table and remove or rename a column you know exactly which queries are now broken at build time. If you were generating or hardcoding sql there's a chance that you hosed a lot of things and need to dig through all the code. Dynamically creating queries is amazing in LINQ. Building them with strongly typed expressions is much better than messy string concatenation.
  - jasonkester 16y ago
    Again, that's not unique to LINQ. Drop a db column in the thing we use and the project will fail to compile until you fix up the references. And of course, if you're keeping your stored procedures in source control and recompiling them at build time (which of course you should), you'll know when you break them too. As you say, strongly typed dataobjects are pretty cool. Regardless of how they interface with the database.
pilif 16y ago
In contrast to client-side JS in case of SQL, there are at least some cases where limiting oneself to a single target can make sense. Not every application needs to run on a pletora of different databases. In addition, over time, the official SQL standard got better and better (quite unlike EcmaScript which took a 10 year break and then returned with minimal improvements) and the databases began following the standard more and more as being standards compliant became a selling feature (which is also quite unlike the ecmascript case where not even the innovative browsers support all of the new features from ES5) Hence, I would claim that the need for an SQL abstraction layer is way smaller than it is for client-side JS
ant5 16y ago
Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. The problem here is that you stop thinking about your data as an independent thing that must be designed for long-term persistence. Code itself should be mutable, easily changed and modified. The on-disk data is the opposite of this -- it must be iterated on carefully, and its requirements must be clearly defined as to be supported in the long-term. I'm very wary of tools that do not make it easy to explicitly and rigorously define the data model entirely separately from the object model that will be used to represent it in a specific version of one application. I think tools like LINQ are valuable because they make working with relational algebra and projections cleaner, but do not abstract the fact that you are working with a long-term persistent data store that is not the same thing as your comparatively short-lived object graph.

by sjs 16y ago

jasonkester 16y ago

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. That's not unique to ORM. We don't use an ORM at Expat, yet all our objects still have .Load() and .Save() methods. I hope you didn't read my post to mean I advocate hand-writing your CRUD! I think LINQ is a great example of needlessly re-inventing something that wasn't very hard in the first place. Especially since its syntax is so close to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot of trouble?

heresy 16y ago
LINQ is far more useful than just as language sugar over SQL. The amount of boilerplate it removes is substantial for anything working with sequences. I actually havent used the SQL backend for it. But since I often work with large collections of heterogenous data outside of a DB, I use it all the time to transform and filter collections in ways that would be very tedious in other languages. Libraries can get you some of the way there, but the language integration is what makes it so painless.
vyrotek 16y ago
There's a lot of power and flexibility using a Model with LINQ. The strongly typed nature has saved me many times. When you alter a table and remove or rename a column you know exactly which queries are now broken at build time. If you were generating or hardcoding sql there's a chance that you hosed a lot of things and need to dig through all the code. Dynamically creating queries is amazing in LINQ. Building them with strongly typed expressions is much better than messy string concatenation.
- jasonkester 16y ago
  Again, that's not unique to LINQ. Drop a db column in the thing we use and the project will fail to compile until you fix up the references. And of course, if you're keeping your stored procedures in source control and recompiling them at build time (which of course you should), you'll know when you break them too. As you say, strongly typed dataobjects are pretty cool. Regardless of how they interface with the database.

pilif 16y ago

In contrast to client-side JS in case of SQL, there are at least some cases where limiting oneself to a single target can make sense. Not every application needs to run on a pletora of different databases. In addition, over time, the official SQL standard got better and better (quite unlike EcmaScript which took a 10 year break and then returned with minimal improvements) and the databases began following the standard more and more as being standards compliant became a selling feature (which is also quite unlike the ecmascript case where not even the innovative browsers support all of the new features from ES5) Hence, I would claim that the need for an SQL abstraction layer is way smaller than it is for client-side JS

ant5 16y ago

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. The problem here is that you stop thinking about your data as an independent thing that must be designed for long-term persistence. Code itself should be mutable, easily changed and modified. The on-disk data is the opposite of this -- it must be iterated on carefully, and its requirements must be clearly defined as to be supported in the long-term. I'm very wary of tools that do not make it easy to explicitly and rigorously define the data model entirely separately from the object model that will be used to represent it in a specific version of one application. I think tools like LINQ are valuable because they make working with relational algebra and projections cleaner, but do not abstract the fact that you are working with a long-term persistent data store that is not the same thing as your comparatively short-lived object graph.