Actually, very similar, since Entity Framework is usually used. Sources implement the IQueriable interface which lets you write queries with method chaining or LINQ. To be honest, it kinda looks better than it is. In reality I find it produces sub-optimum performance and a lot of things can not be done without spilling query logic to the app. Not to mention a lot of linq/method chaining queries cannot be translated to SQL (by the database provider).
The repository pattern in the original example would allow you serailise your objects to whatever datastore you want. His object design isn't that great for being persistence ignorant though. I would instead do something like this.
Course - Aggregate Root
Student - Aggregate Root
RegisteredCourse[] - RegisteredCourses - An array objects with date time of registration, and id reference to course.
The method for adding a course would simply create a new RegisteredCourse and place it in the registered courses array.
_studentRepository.save(student) would be a simple matter converting this in memory representation into sql.
I'm not big fan of using lazy loading, and direct references to other aggregates inside of other aggregates. This makes mapping these models without ORM difficult.
