My new boss wants to get rid of llblgen Pro for Linq.

We have been using LLBLGen for four years and I need very strong arguments to repel this move.

Though I have used LLBLGen for a long time, and I have less information of Linq2SQL I don't have any strong arguments why we shouldn't.

One of the things the boss is boasting of is the syntax of Linq being simple, short.

I need some reasons why there is no need to move to Linq.

If your boss wants to use Linq to Sql because he wants to use Linq, he can keep on using LLBLGen Pro, v2.6 has a solid Linq provider so you can use Linq (which is a language construct in C# / VB.NET! ) and use LLBLGen Pro.

Linq to Sql is not the same as 'Linq'. Linq to sql is a simple O/R mapper which has a couple of drawbacks: - no M:N relationships - no target per entity inheritance - no multiple catalogs per project - no solid prefetch paths - only SQL Server - no UDT CLR support for sqlserver clr udt types - weak support for sqlserver 2000 - query compilation is very slow. - no typed views/lists - no auditing support - no validation support - no flexible concurrency like we do - no authorization support - it's hierarchical fetch code for linq queries nested into other linq queries is very inefficient. - designer is very limited, everything has to be on 1 canvas, so with 30 or more entities this becomes very problematic. There are other drawbacks with the linq to sql designer; it doesn't support refreshing the catalog (so you have to start over!), no solid name construction during reverse engineering, no template based code generation etc.

As LLBLGen Pro has a solid linq provider, I don't see why there's a reason to use Linq to Sql. Please check out v2.6 on our website. Docs here: http://www.llblgen.com/documentation/2.6/hh_goto.htm#Using%20the%20generated%20code/Linq/gencode_linq_gettingstarted.htm

Thanks a bunch

gittaylor wrote:

Thanks a bunch

Btw, I forgot, we have Linq to sql templates as well. So use our designer with linq to sql if you want to