Well, it's mostly covered in answers here (some interesting points of view as well) already, but I'm going to say it again anyway..
LINQ to SQL (L2S) is very versatile, but it feels a tad too basic from my viewpoint. In most cases it does a good job at doing simple things, but as soon as you ask a little more of it, it gets expensive. This isn't at all a bad thing. I actually think LINQ to SQL actually suppliments the Entity Framework nicely.
Take Auto Paging with LinqDataSource for example. If you don't specify Order By/Group By then it's quite economical. Throw ordering or grouping into the mix and you start to get a spike in performance (becomes very chatty). You then pretty much have to write your own paging implementation (which isn't terribly hard, I'll admit).
I'll be the first to admit that L2S has the advantage over the Entity Framework in terms of the quality of the generated T-SQL (I should, since L2S is specifically built for querying SQL Server) and conceptually and symantically, much of LINQ to SQL is similar to EF, but where you hit the wall is on expanding needs and consideration for more complicated implementation requirements.
If I were to start from scratch and choose to devote personal development time, I'd pick the Entity Framework. Interestingly enough, I'm working on a project at the moment which uses L2S and it is being designed to scale nad handle heavy loads, but when we hit some of the more "creative" requirements, we are often forced to expand on SQL Metal (e.g. many-to-many relationships).
So.. in short.. I'd approach it thus:
a) learn LINQ to SQL as an intro (to Microsoft's ORM patterns and technology).. it gets you familiar with most of the fundamentals which are shared with the Entity Framework, and a taste of LINQ style querying (an acquired taste if you have a background in T-SQL)
b) once you've got a handle on LINQ to SQL, I'd recommend jumping over to the Entity Framework to learn the additional benefits (eSQL etc)
c) Implement a proof of concept project in both and compare the results.
I have used the classic old ADO.NET for many years, and you just get used to it. For a larger application, you can invest some time in creating a data layer once, then re-use it with many other business objects.
A couple of other options:
- Strongly Typed datasets. You can create a strongly typed dataset that will allow you to drag and drop database objects and will generate a lot of the plumbing code for you.
2 linq To Sql designer, which also allows you to drag and drop objects into a designer, and generates a dbml file that you use to connect and manipulate your data.
I have recently gotten onto the Linq bandwagon and it does simplify your life when treating data as objects.
Good luck!
Best Answer
Other individuals and organizations have spent months or years developing their own ORMs and technologies -- many of which you listed -- and many are free to use. You should devote your resources toward your core application logic instead of trying to build another whole beast called ORM. There are enough offerings out there to satisfy all kinds of applications.
You said you've never been involved in building your down DAL. It's a classic starting error to try to roll your own resulting ORM (as far as time and resources, not necessarily knowledge), for those reasons stated above. If you think some of the existing offerings seem overkill, just wait until you get into the intricacies of building your own.
However if you want to compete in the ORM market and that IS your product, then go right ahead. That's my 2 cents.
Edit: If you have concerns about being bound to a certain ORM product or offering in your project, you can simply hide away whatever software you choose behind an interface and swap in other ORMs as needed...
And if someday you have some free cycles and want to build your own ORM, even after trying other products, you can just slip it in behind this interface too.