Doesn't Linq to SQL Miss the Point? Aren't Orm-Mappers (Subsonic, etc.) Sub-Optimal Solutions

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

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.

what does it mean by LINQ to SQL is an ORM that allows the direct 1-1 mapping of a Microsoft SQL Server database to .NET classes?

This is not necessarily a comprehensive answer, but it should clarify the most common case where this comes up.

If you have a many to many relationship between users and groups, LinqToSql will create 3 classes: User, UserToGroup, Group. Entity Framework will create 2 classes: User, Group.

It is awkward to most people to have a UserToGroup class (essentially a relational database construct to resolve a many to many relationship) exposed in the code model. It's way more natural in code to navigate from a user to the groups the user is in, then to have to navigate through an extra, meaningless class.

This is generally seen as a "limitation" of LinqToSql. I can't think of another .NET ORM with this "feature", every other one I know of supports the Entity Framework way.

Linq to SQL vs Access SQL - Why aren't Take() and TOP the same?

var topThree = collection.OrderByDescending(c => c).Distinct().Take(3);
var top = collection.Where(topThree.Contains).OrderByDescending(c => c);

That should do what you want. You could easily wrap it into an extension method.

Do i need to learn DataSet?

LINQ to SQL does not depend on DataSets. Don't learn them.

You might even want to skip ahead to Entity Framework because L2S is abandoned (alas!) by Microsoft. EF is the declared future.

Don't ever learn a predecessor technology first if you are actually interested in the successor. Learning materials for successor technologies make sure you get to know everything that is important. If DataSets were important your learning materials would tell you so.

Confusing MVC and LINQ to SQL

First, notice the date on that article. It's from 2009. That means it precedes Visual Studio 2010 and .net 3.5. The article is talking about Entity Framework 1.0, which had a large number of problems, and thus it was often recommended to use Linq to SQL rather than EF 1.0.

However, as of VS 2010 and EF 4.0, most of those concerns were addressed and EF is now the preferred method over Linq to SQL. L2S is still supported, but Microsoft is no longer doing any major improvements to it.

As others have mentioned in the comments, MVC is database agnostic. You can use any database technology with it, and it is not dependent on EF in any way. You can use EF, L2S, nHibernate, ADO.NET, etc... You won't "break MVC" because MVC has no concept of your database technology.

Many people still implement repositories and Unit of Work on top of EF (although I personally see that as extra work unless you plan to need a database abstraction that allows you to change technologies).

EDIT:

Upon further reading of the article, I don't see anywhere where it recommends L2S over EF, in fact at the end of the article it has this comment:

Suppose If you want to change the data access technology using EF ( Entity Framework) instead of LINQ TO SQL you simply implement the IStudentRepository interface with a class that uses the alternative database access technology

Dynamic where condition in Linq to Sql or Linq to Entity

Dynamic LINQ should work for you.

Most complete ORM with LINQ support?

NHibernate with Linq to NHibernate

---

Related Topics