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. That's not uniq

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.

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.