This item is here both to capture the possibility of supporting pattern similar to LINQ to SQL’s [DataLoadOptions.LoadWith](http://msdn.microsoft.com/en-us/library/bb548760.aspx) and to capture some basic thoughts regarding the proposal for [Graph-based querying for Entity Framework](https://entityframework.codeplex.com/discussions/441726#post1036324) made by [Merijn de Jonje](https://www.codeplex.com/site/users/view/MdeJ).
To give some context, the proposal provides this example query:
```
var shape = new EntityGraphShape(context)
.Edge<A,B>(x=>x.Bs)
.Edge<B,C>(x=>x.C);
shape.Load();
```
At a glance, the fundamental difference between this way of specifying graphs queries and the existing Include method in EF is that while the later is restricted to only allow specifying navigation properties for the entity type of the source query to which it is applied this Edge method allows you to specify the starting point of the edge in the generic parameter of the call itself.
For very simple queries Include's approach has the benefit of leveraging type inference, allowing the user to "dial" into the right navigation properties for the source entity type with help of Intellisense. But for more complex queries the restriction forces the user to write much more complex code to be able to chain the right navigation properties to the right types. Include in fact stops being useful very soon, e.g. currently it does not support inheritance, and most of the work has to go into writing a complex projection.
While Edge on the other hand does not help that much with simple queries, it provides a flexible way of adding separate edges to a query as simple metadata, which can lead to a more declarative approach and to leaner queries. In that sense Edge is actually an inline version of LINQ to SQL’s [DataLoadOptions.LoadWith](http://msdn.microsoft.com/en-us/library/bb548760.aspx).
Some additional considerations:
* It is very unlikely that we could take Merijn's graph-based queries as a contribution "as is" since his implementation is completely independent and incompatible with EF mapping and basic building blocks. However, we can possibly support a method similar to his Edge in the future.
* We should consider using the word Include in the name of the method for inline rules as well as for a "load options" pattern, as the semantics of Include are well-known to our customers. Unfortunately I believe it would be very difficult to reuse the name Include in a method that takes an IQuerayble<T> source but does not restrict the rest of its arguments based on T.
To give some context, the proposal provides this example query:
```
var shape = new EntityGraphShape(context)
.Edge<A,B>(x=>x.Bs)
.Edge<B,C>(x=>x.C);
shape.Load();
```
At a glance, the fundamental difference between this way of specifying graphs queries and the existing Include method in EF is that while the later is restricted to only allow specifying navigation properties for the entity type of the source query to which it is applied this Edge method allows you to specify the starting point of the edge in the generic parameter of the call itself.
For very simple queries Include's approach has the benefit of leveraging type inference, allowing the user to "dial" into the right navigation properties for the source entity type with help of Intellisense. But for more complex queries the restriction forces the user to write much more complex code to be able to chain the right navigation properties to the right types. Include in fact stops being useful very soon, e.g. currently it does not support inheritance, and most of the work has to go into writing a complex projection.
While Edge on the other hand does not help that much with simple queries, it provides a flexible way of adding separate edges to a query as simple metadata, which can lead to a more declarative approach and to leaner queries. In that sense Edge is actually an inline version of LINQ to SQL’s [DataLoadOptions.LoadWith](http://msdn.microsoft.com/en-us/library/bb548760.aspx).
Some additional considerations:
* It is very unlikely that we could take Merijn's graph-based queries as a contribution "as is" since his implementation is completely independent and incompatible with EF mapping and basic building blocks. However, we can possibly support a method similar to his Edge in the future.
* We should consider using the word Include in the name of the method for inline rules as well as for a "load options" pattern, as the semantics of Include are well-known to our customers. Unfortunately I believe it would be very difficult to reuse the name Include in a method that takes an IQuerayble<T> source but does not restrict the rest of its arguments based on T.
