Doesn't Linq to SQL miss the point? Aren't ORM-mappers (SubSonic, etc.) sub-optimal solutions?

Question

I\'d like the community\'s take on some thoughts I\'ve had about Linq to Sql and other ORM mappers.

I like Linq to Sql and the idea of expressing data access logic (

Answer 1

there´s no problem with linq, but with those who use it and ignore what happens "behind the scenes"

I still prefer to get my hands dirty with SQL. At least i´ll know exatcly whats happening.

Answer 2

For at least 6 years I have been using my own ORM that is based on a very simple concept: projection. Each table is projected into a class, and SQL is generated on the fly based on the class definition. It still requires me to know SQL but it takes care of the 90% simple CRUD, and I never had to manage connections, etc - and it works for the major DB vendors.

I'm happy with what I have and didn't find anything worth dropping it for.

Answer 3

Linq's design and the linq to entities framework certainly has uses as an orm tool, but the big idea is that it will be used as a common api to query ANY data source, not just RDBMS's.

I remember reading that linq, while obviously designed with SQL in mind, is meant to be a query language for any data store. You can write linq queries for SQL, but you can also theoretically write linq queries that target ldap, filesystem's, exchange, web services, ad infinitum. You can't use SQL for those programs.

You also need to learn a different API for almost every data store. Linq gives everyone a common target to create a data access API.

Whether this vision works or not remains to be seen, but that is the idea. I think as we want systems to inter-operate more and more we may find some very nice uses for l2e.

I'll add some references if I can find them again.

http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/

Answer 4

You should stop worrying and learn to love the ORM. Abstractions such as these will help us focus our skills and make advances in the field.

There is still plenty of room to take advantage of the functional skills you have acquired and apply them in the application layer. This is in fact one of the strengths of LINQ to SQL over other ORM's.

I can only agree with many of the other comments. The time you save, you can focus on refining your domain model and make a better application. And, once you've pinpointed the bottleneck, use to create optimized SQL.

What might not be immediately obvious is that the ORM comes with a number of features that are really nice. The identity map that helps avoid loading items over and over, lazy loading helps you express the domain with less plumbing and the unit of work helps you track changes and optimize database writes.

Answer 5

Historical perspective.

When Codd et. al. originally were working out the theory and implementation of relational databases, one entirely separate issue was "How do we query these things"? A number of strategies and syntaxes were proposed, with various strengths and weaknesses. One of those candidates was SQL (in its earliest form, obviously.) Another was QBE (Query By Example). Another was called "quel", I believe; and there were several others. SQL certainly didn't become dominant because it was acclaimed as superior to all others. Unfornately, though, the others have pretty much disappeared, to the poverty of us all (because they could be used simultaneously on the same data.)

If Microsoft has a good story that they are reviving one of these other languages, or have invented a worthy addition, then I think we would be well-advised to listen up. But so far all I've seen is yet another "One Ring To Rule Them All".

There's a hell of a lot of thought and rigor behind SQL, and a lot of time-proven durability. Microsoft has a certain history of believing that their admittedly top-grade development organization can out-think the rest of us, including our collective institutional memories. It doesn't seem often to work that way. As long as we're bonded to relational data stores, we should think twice about superset abstraction paradigms that move us away from the bare metal with promises of equal or better performance.

Answer 6

Codemonkey makes a very good point: stored procedures offer a level of abstraction that fulfills some of the promise of the more complex ORM models. This isn't intuitive at first glance but I can think of an example right from my own code. I have a "check-in" sproc that touches nearly a dozen tables (who does this ID belong to? do they have a membership? Are there any messages? Do they get points for this check-in? etc.).

Modeling this in C# - no matter how sophisticated the data model - would never be a good idea as it would necessitate many trips "over the wire" to check on data and update various tables. While it is true that you can handle sprocs in Linq or other ORMS, all I need is a wrapper class that allows me to call the sproc with standard C# parameters. In fact, this was such a pressing need for me that I wrote a code generator in T-SQL to create such wrappers.