ADO.NET vNext Future Directions
Ever since I announced the release of the ADO.NET August CTP I have done my best to participate in the community, with the little spare time I have. The key takeaways for this week are:
Spans to pre-fetch data is something the team is exploring but no form plan yet [discussion]. As an application developer it is necessary to have a certain level of control to load the appropriate graph for a certain context. Nearly all object-relational mapping implementers ran into this issue, and solved it using smart spans/prefetch implementations. In Neo we exposed this functionality with a convenience method AddSpans, so you can pass an array of property paths to entities that should be fetched alongside the main entity. For example querying an order with the following span query.AddSpans("OrderLine.Product", "Customer") would return the order and its customer, and its associated order lines and product.
GetObjectByKey as a convenience method [discussion]. Neo as well as NHibernate already use this pattern.
RejectChanges to make the ObjectContext effectively forget all objects and their changes [discussion]. Pablo Castro [ADO.Net Technical Lead] questions whether this is functionality being used enough to push it to be an API in the top-level object. Neo benefits greatly from having this functionality in rich client scenario's and with our nested object context feature (parent/child pattern).
Batch updates to delete or update a number of records in one go [discussion].
Dynamically define entity attributes at runtime is very useful to change and store mapping information without a recompile [discussion]. iBATIS made this possible through flexible result set mapping and a configuration file watcher to reload meta data without having to restart the application. This proved to be very useful in our web applications.
Entity Data Model move to the server is something Microsoft envisions [discussion]. Long-term this is likely to become the foundation for a number of Microsoft's efforts as many aspects of data management will benefit from the higher abstractions that the EDM can provide. A while ago my friend Jimmy came up with the idea to create an abstraction layer on top of different persistent solutions he calls NWorkspace. Who ever said this higher abstraction should be exposed as an API ;) This idea was well ahead of his time.
Properties on a relationship is an upcoming feature to be able to nicely map a Book -> BookAuthor -> Author structure in the logical view against Book -> Author in the conceptual view [discussion].