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.
