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.
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.
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