Another piece of feedback was concerns over the WinFS api’s being a different data access pattern than our existing managed code data access APIs. Further, that our APIs were not aligned with broader data platform needs like OR mapping. This was a big one, and as you explore the SDK and the APIs, you will see the beginnings of how we will be addressing this. We are in the process of building-out the next version of ADO.NET to have new features that provide a data model, object-relational mapping, and flexible query infrastructure. The new data model is about entities, and the WinFS data model of Item types is built on that model. Looking through our SDK and code samples you will see how Items are composed of underlying entities. OR mapping is a big requirement - WinFS is a very prescribed mapping (defining a type in WinFS generates both the underlying storage schema and the partial class to program to that type). But the real-world has lots of requirements for flexible mapping – to existing data, to existing objects, etc. On query, many of you have heard about Anders Hejlsberg’s work on Language Integrated Query – and the new ADO.NET functionality will plug directly underneath so that you can use the new query patterns on any entity data, including of course now WinFS Items.So, my personal understanding is that ObjectSpaces and C-Omega evolved and became the Integrated Query Framework, which is tightly integrated wth the CLR and the .NET languages. At the same time WinFS will be built on that, instead of using previous technology.
So, I guess part of the reason WinFS was delayed was they found that it made more sense to wait and get it right from the beginning. Then, I am grateful!
