http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Hey Ayende, probaby a bit late now for you but a coleague of mine wrote an article on how to do DI with LINQ to SQL, so you can make it a bit provider based. You can find it here - [www.codeproject.com/KB/linq/LinqAndUnity2.aspx](http://www.codeproject.com/KB/linq/LinqAndUnity2.aspx) (I did chastise him for using CodeProject though :P) http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment9http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment9Mon, 16 Nov 2009 11:13:02 GMTI'm a big fan of L2S and use it at work, mainly because of its simplicity and because it's a much easier sell to a team that isn't chalk full of uber coders than some other ORM tools. Anyone with any OO and ADO.NET experience in .NET can ramp up with L2S and understand what it's doing without much time investment. It also plays nice with vanilla ADOO.NET and existing SqlTransactions. However, you're right - it does have some pretty big limitations, of which the 3 biggest in my opinion are that it's SQL Server only, it's one class per table only, and it's difficult to know how to build a more formal DAL without running into issues with the DataContext object's convoluted lifecycle. But for many small dev shops, those limitations aren't such a big deal and are outweighed by the RAD L2S provides. That said, I think you make an interesting point about L2S architecture, and how some of its limitations aren't technical, but are due to MS strategically crippling it for use with other providers. But it's also interesting that regardless of what MS allows with it, L2S has shown what is *possible*, and that there's a huge untapped market for an easy to use tool like L2S to wean people off of DataTables. I think that the popularity of L2S also shows that there was a missed opportunity for Castle's ActiveRecord to get itself out there more. AR has a huge advantage in that it's still NHibernate under the covers, but it's not very well known and doesn't seem to have the momentum that L2S has. Maybe the MS blessing made L2S what it is, but I'd still like to see AR develop as somewhat of a gateway drug to get NHibernate in the door in some of these smaller shops. That's the disconnect that MS will struggle to overcome as it tries to convince people to go from L2S to EF which are two totally different tools. And that's a huge advantage that AR+NHibernate have over L2S+EF, if only someone would notice the opportunity. http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment8http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment8Mon, 16 Nov 2009 03:32:28 GMTDmitry, No, EF Prof is completely non invasive. http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment7http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment7Mon, 16 Nov 2009 02:50:40 GMT@Julie: thats entirely plausible to me. would not have been the first time that two teams are doing the same thing at microsoft. looks like the c# team knew what they were doing a little better. http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment6http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment6Mon, 16 Nov 2009 02:13:01 GMTOren, would you need to register a DbProviderFactory for the EFProf? http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment5http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment5Sun, 15 Nov 2009 22:31:30 GMT@tobi - The story goes that L2S was being developed by the C# team at the same time that EF was being developed by the Data Programability team. Neither team knew what the other was doing and there was quite a surprise. http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment4http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment4Sun, 15 Nov 2009 22:14:40 GMTThat code came from the original team, as was the provider interface being private. Even with it private SqlCE support still could have been written as a separate provider without IProvider being public so the argument doesn't hold. What likely happened is somebody thought the SqlCE stuff would be a few relatively simple switches but it grew and grew and it looks like it never got refactored into it's own mechanism. [)amien http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment3http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment3Sun, 15 Nov 2009 18:48:03 GMTIt is interesting that they are adding the features of L2S to EF. http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment2http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment2Sun, 15 Nov 2009 16:41:50 GMTi wander what caused microsoft to (seemingly) build EF from scratch and with a radically different architecture. L2S couldn't possibly have been that bad. In fact they deliberately threw out lazy loading which is ... ah ... not so smart. I say deliberately because they could have implemented a slim version in a few hours by adding into the codegen "if(!Loaded) Load() return innerCollection;". This is the exact code one has to write manually now. http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment1http://ayende.com/4292/some-observations-on-linq-to-sql-entity-framework-codebases#comment1Sun, 15 Nov 2009 15:43:39 GMT