Is it possible to navigate entities in Entity Framework as easily as it's done with typed datasets?

Question

Is it possible to navigate entities in Entity Framework as easily as it's done with typed datasets?

With typed-datasets you load many tables from one sproc and then simply use statements like:

//get student’s course StudentsDS.Course drCourse = drStudent.CoursesRowParent;

// get course students foreach (StudentsDS.StudentRow dr in ds.GetStudentsRows()) { … }

I have a new project and must decide if plunging into the EF trend or keep the true and tested. BTW, I read a lot of criticism of typed-datasets that is plain wrong or exaggerated.

For the new project I am going with ASP.Net MVC because I am convinced of its advantages. With EF... not so sure.

Answer 1

Of course, you can. Hard to given an example out of nothing, but I tried. The following code will print the name of all students that are in the first course of "John Doe" containing "Algorithm" in the course name.

using (ObjectContext context = new ObjectContext())
{
    foreach (Student student in context.Students
        .First(student => student.Name == "John Doe")
        .Courses
        .First(course => course.Name.Contains("Algorithms")
        .Students)
    {
        Console.WriteLine(student.Name);
    }
}

If you want to access other relationships, you have to explicitly load them or use the Include() method.

using (ObjectContext context = new ObjectContext())
{
    foreach (Student student in context.Students.Include("Courses"))
    {
        foreach (Course course in student.Courses)
        {
            Console.WriteLine(student.Name + " " + course.Name);
        }
    }
}

Or using explicit loading.

using (ObjectContext context = new ObjectContext())
{
    foreach (Student student in context.Students)
    {
        if (!student.Courses.IsLoaded)
        {
            student.Courses.Load();
        }
        foreach (Course course in student.Courses)
        {
            Console.WriteLine(student.Name + " " + course.Name);
        }
    }
}

Answer 2

It looks to me like the fundamental argument here is whether you think using an OR/M (Object Relational Mapper) is a good idea or not and whether such an approach has any advantages over the typed DataSet approach you are used to. From my experience, use of an OR/M is fundamental in any application that I develop that requires persistence and see this post by Glenn Block (who puts it far better than I can) for the reasons why.

Answer 3

Accessing the related objects is as easy as it is in typed datasets. You'll find differences in loading the data, though. The part you'll find most different is that Entity Framework (and Linq to Sql as well) de-emphasizes the use of stored procedures as a means to fill your data collections. It's possible, mind, just not as flexible as it is in the datasets you're used to. So loading multiple EntitySets (i.e. DataTable equivalents) from a single stored procedure call isn't really that useful in Entity Framework because there's no real DataAdapter equivalent. That said, Daniel Brückner's handy examples above will show that you can populate multiple entitysets in a single call to the underlying datastore very easily. Indeed, I find it easier to do so in Entity Framework (and Linq to Sql) than in strongly-typed DataSets.