So it looks like MSFT has decided not to include the ObjectSpaces O/R technology in Whidbey (just can't call it VS.NET 2005 yet). Note: at the time of this entry, it's also mentioned on the main MSFT Data site.
Does that suck? Maybe if you're the guy who was responsible for getting it done, but I don't see a reason to worry about it. In fact, I see a few reasons to feel pretty OK with it:
- There are plenty of third-party tools out there that do this already. We've been using Olero's ORM.NET product and it's been great for us. There are even some open-source O/R tools that get pretty high marks.
- Maybe by binding ObjectSpaces to WinFS, they're looking past just mapping a relational database to objects. Maybe they're looking at an O/S (Object/Storage) implementation that's not just hooked into SQL Server, but is also aware of the common entity types being talked about with
WinFS (person, company, document, etc). Or maybe not. But given the dramatic changes to storage for Longhorn, there's no question that they have to be looking at a OO interfaces for that storage today.
- Many of the people complaining now about the schedule slip would be similarly complaining if it DID ship with Whidbey and sucked. I'd rather have it late and stable than sooner and not production-ready.