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

I just discovered this question. I guess it's pretty much played out by now, but I'm going to throw in my two cents anyway...

I only want to write code for the things that aren't obvious.

CRUD code is obvious. I don't want to write it. Therefore, ORMs are a good idea.

This doesn't mean that ORMs don't have problems, but the problems are with execution, not intent. As ORMs mature, the problems will diminish, and the productivity gains already available for simple scenarios will eventually extend to complex scenarios as well.

LINQ is also a good idea. Others have mentioned a number of the advantages, but all I have to do is think about the first time I tried to do a pivot in LINQ where I didn't know the number of columns in advance. Or the first time I realized I didn't have to create a new DataView every time I wanted to sort or filter something. LINQ empowers me to do everything I want to do with data in C#, rather than having to figure out how divide up the work between SQL and C#.

So, yes, ORMs, LINQ, and other emerging technologies are suboptimal solutions, but they don't miss the point, and they won't be suboptimal forever.

Answer 2

As Dmitriy pointed out, developers don't know SQL. More precisely, the majority know SQL, but don't understand it and definitely don't like, so they tend to search for the magic bullet, creating the demand for things like Linq to make the illusion (hm, abstraction) that they don't use anything different than their beloved classes.

That's very bad, as the law of leaky abstractions always holds true.

Some ORM solutions are definite good (e.g. JPA/Hibernate), not because using them you don't have to worry about SQL. In fact, to use JPA effectively you need very deep understanding of the DB in general, querying abilities in particular. The good point is that they make the machine do the boring work, to the point where it autogenerates entire database from scratch.

Linq to SQL, as I think, doesn't solve real problem. It's kind of other presentation, nothing more. It might be good, though it overcomplicates the already complex language. On the other hand, Linq to Objects is very interesting concept, because it's kind of sql-querying the collections.

Answer 3

Being the author of an ORM project myself, I have to admit that my response to a question like this is apt to be a bit biased. I've already developed some of my own thoughts about the answer prior to reading the question, so I'm already somewhat anchored.

I will say that my reason for developing an ORM wasn't because of the "impedance mismatch" between SQL and imperative programming, but rather solely for the purpose of becoming database-platform agnostic. The former issue of having to write more code to manage persistence is a small hurdle that's easily resolved if you only work with one database vendor. Becoming database platform agnostic is a much more challenging problem and imo has a much larger impact on the profitability of your business assuming that like me you plan to sell software to other people (and are not just using it in house).

When I started working on my ORM tools several years ago, the concept was impractical in my preferred language, most people I spoke to didn't understand why I was working on it and some well respected voices in the community had as much as written articles in trade magazines stating that what I had already done was not only impossible but also undesirable. Some of the same reasons were given - it's too complex, it's limiting and it adds overhead. Today the same community has at least three popular database abstraction tools (although there is some debate about the definition of the term ORM). The reason why I mention this is because when I started working on these tools, the original objections carried a lot more weight than they do now. The underlying technology both hardware and software has changed in the intervening years to make these tools much more practical in the long run. My tendency is to try and take a long-view of software and work on solutions that are maybe not quite practical yet but that will become practical soon. So given that I wouldn't count out LINQ to Entities as a good solution for certain problems.

I also tend to prefer more options rather than less. So while I may support the idea behind developing LINQ to Entities, I'm less apt to support killing off LINQ to SQL merelyu because LINQ to Entities has become available. Objects are great for doing what objects do, there's no question about that... In my (again biased) opinion, a problem occurs in that people see any given tool or software paradigm as a "magic bullet" and want to insist that everything must be that way. It's well known that a relational database is very good at handling certain other tasks, reporting being a good example. So in my opinion, it's kind of shooting yourself in the foot to insist that everything must be entities, because then you're forcing yourself to use an inefficient tool for the job. So with regard to reporting in particular, getting rid of LINQ to SQL and using only LINQ to Entities at least on the surface sounds to me like the abstraction inversion anti pattern.

So I guess the synopsis for my answer is this: use a hammer if your problem is a nail - use a screwdriver if your problem is a screw.

Answer 4

Ted Neward wrote a great essay on his take on this subject - that ORM's are the "Vietnam" of computer science...

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Answer 5

I think the popularity of ORMs has been spawned by developers developing data layers and writing the same CRUD code over and over again application after application. ORMs are just another tool/technology that lets developers spend less time writing the same SQL statements over and over and concentrate on the logic of the application instead (hopefully).

Answer 6

IMHO, OR/M is not only about 'abstracting the SQL away' or hiding the SQL, or enabling multi-DBMS support.

It enables you to put more focus on your problem domain, since you have to spent less time writing the boring CRUD SQL queries. On the other hand, if you are using a good OR/M, this OR/M should enable you to write SQL queries if this seems to be necessary.

An OR/M can be a powerful tool if you use it properly; it can take care of lazy loading, polymorphic queries / associatons ...
Don't get me wrong; there's nothing wrong with plain SQL, but, if you have to take care yourself of translating your (well thought and normalized) relational model to an expressive OO/domain model, then I think you're spending way to much time doing plumbing.

Using an OR/M also does not mean that you -as a developer- should have no knowledge of SQL. The contrary is true imho.
Knowing SQL and knowing how to write an efficient SQL query, will -imho- enable you to use an OR/M properly.

I must also admit that I'm writing this with NHibernate in mind. This is the OR/M that I'm using atm, and I haven't used Linq to SQL or Linq to entities (yet).