views:

379

answers:

1

Why in Linq to Entities do I need to specify relationships with Include(string)? Linq to SQL doesn't need to.

Is this a choice of developers or limitation?

Another problem, Linq to SQL is more "POCO" class, Linq to Entities is too complex.

+7  A: 

Linq to Entities (the Entity Framework) is a lot more complex than Linq-To-SQL - but it's more complex because it allows a lot more flexibility.

In Linq-to-SQL, you basically get a 1:1 mapping between database tables and your .NET classes in memory. That's fine for a lot of simpler scenarios, and that's where Linq-to-SQL really shines.

But in larger, more complex enterprise scenarios, this might not be sufficient. The Entity Framework and thus Linq-to-Entities allows you to have a separate conceptual model (your .NET objects) that is not necessarily tied to your database structure on a 1:1 basis (inheritance, merging multiple tables into a single object and more of those). While this may sound too complicated and too complex, in many advanced scenarios, this is a life-saver and a must-have-feature.

So I don't think you can compare Linq-to-SQL and Linq-to-Entities (the EF) against one another - they're really made for different, separate problem spaces, with different requirements and thus also different approaches / styles of programming.

If Linq-To-SQL is good enough for you and your requirements - great - use it, by all means!

Marc

marc_s
Oddly enough I couldn't get my current crazed scheme (views overlaying two databases to present a single interface into logical objects which span the databases) to work in Entity Framework because of difficulties with setting keys up on entities derived from views. Was cake with LinqToSql.
Telos