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 accept navigation properties for the entity type of the source query to which it is applied, the 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 allowing the user to "dial" into the right navigation properties for the source entity type with help of type inference and Intellisense. But for more complex queries the restriction forces the user to write additional code just to wire up the right navigation properties to the right types. Include in fact stops being useful very soon, e.g. if you need to refer to properties that only exist on derived types, and for the most complex query scenarios the user ends up needing to write even more complex projections.
While Edge does not help much with writing simple queries correctly it provides a more flexible way of "annotating" a query with metadata about the edges that should be traversed. This can lead to syntax that feels more declarative and can express more complex queries with significantly less code.
Edge is in fact an inline version of LINQ to SQL’s DataLoadOptions.LoadWith.
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 query pipeline. However, we can possibly support a method similar to his Edge natively on EF 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.
Comments: Some additional notes related to this item: * In addition to the expressive power of the Edge/EntityGraph approach, specifying a complex query as a graph allows for __very efficient and good performing__ queries. The algorithm to derive SQL queries from these declarative graph-based queries results in highly optimized and dedicated SQL. * As indicated above, I completely bypass the EF pipeline for querying. Only after the query completes, the resulting entities are attached to the EF context. The reason for this is my lack of knowledge about how the EF pipeline works. Perhaps we could have some discussion with the EF team about this topic because it might be possible to tighten the integration of my approach with EF. Some, more general, notes: * Edges are now simply mappings from a source type to a target type (or collection). The approach could be further extended to add conditions to each edge, like for instance: ``` var shape = new EntityGraphShape(context) .Edge<A,B>(x=>x.Bs) .Edge<B,C>(x=>x.C).Where(x=>x.Name == "Foo"); ``` This would further enhance the expressive power of the graph based approach * EntityGraph is a more generic concept to deal with graphs of related entities. Graphs are defined by their graph shape. Initially, EntityGraph was mainly developed for WCF RIA Services, but in the coming months I will release a general .Net version. More information adn examples about EntityGraph can be found [https://riaservicescontrib.codeplex.com/wikipage?title=EntityGraphs](here).
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 accept navigation properties for the entity type of the source query to which it is applied, the 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 allowing the user to "dial" into the right navigation properties for the source entity type with help of type inference and Intellisense. But for more complex queries the restriction forces the user to write additional code just to wire up the right navigation properties to the right types. Include in fact stops being useful very soon, e.g. if you need to refer to properties that only exist on derived types, and for the most complex query scenarios the user ends up needing to write even more complex projections.
While Edge does not help much with writing simple queries correctly it provides a more flexible way of "annotating" a query with metadata about the edges that should be traversed. This can lead to syntax that feels more declarative and can express more complex queries with significantly less code.
Edge is in fact an inline version of LINQ to SQL’s DataLoadOptions.LoadWith.
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 query pipeline. However, we can possibly support a method similar to his Edge natively on EF 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.
Comments: Some additional notes related to this item: * In addition to the expressive power of the Edge/EntityGraph approach, specifying a complex query as a graph allows for __very efficient and good performing__ queries. The algorithm to derive SQL queries from these declarative graph-based queries results in highly optimized and dedicated SQL. * As indicated above, I completely bypass the EF pipeline for querying. Only after the query completes, the resulting entities are attached to the EF context. The reason for this is my lack of knowledge about how the EF pipeline works. Perhaps we could have some discussion with the EF team about this topic because it might be possible to tighten the integration of my approach with EF. Some, more general, notes: * Edges are now simply mappings from a source type to a target type (or collection). The approach could be further extended to add conditions to each edge, like for instance: ``` var shape = new EntityGraphShape(context) .Edge<A,B>(x=>x.Bs) .Edge<B,C>(x=>x.C).Where(x=>x.Name == "Foo"); ``` This would further enhance the expressive power of the graph based approach * EntityGraph is a more generic concept to deal with graphs of related entities. Graphs are defined by their graph shape. Initially, EntityGraph was mainly developed for WCF RIA Services, but in the coming months I will release a general .Net version. More information adn examples about EntityGraph can be found [https://riaservicescontrib.codeplex.com/wikipage?title=EntityGraphs](here).