 |
|||||||||
|
|||||||||
|
|
It might have taken them a couple of extra days to get the release out, but it's finally out. I'm actually glad they waited because we've all been burned before by rushed CTPs. Anybody remember a while back when they pushed out some tools related to either the EF or Astoria (can't remember which), and literally 8 hours after I installed it, there was a patch to the CTP released.
Brad Abrams just blogged about the release of the preview bits. You need to keep in mind that these preview bits are designed to work specifically with Visual Studio 2008 RTM release and no other version. They sit on top and, according to Brad, they are side-by-side so they won't "hork your system". Which is awesome, because nobody likes having their system's horked.
When you're working with this stuff, I highly recommend that you stay very far away from the IIS-based websites. While developing, stick with the Cassini-based (internal VS 2008 filesystem-based) web applications. Astoria will will better, the Entity Framework stuff will work better, and I've had a lot better luck with the MVC stuff. If you need to deploy this stuff to a remote server for someone to look at, you can always use Publish to get the website off your dev box. Also, as we all know, file-based websites are much more source control friendly. I find that looking at an IIS-based website inside TFS is like looking cross-eyed into a kaleidoscope.
Obviously this preview isn't just about the MVC stuff, though that's taken up a lot of my time. There is, of course, ADO.NET Data Services (formerly codename Astoria). One thing to keep in mind about this: this is a really crappy myopic name for this product. These services should not have the ADO.NET moniqer on them at all. Why? Because you can expose any IQueryable data source over RESTful URLs serialized via ATOM.
Let me repeat that so you can let that sink in a bit:
You can expose any IQueryable data source over RESTful URLs serialized via ATOM/APP.
Just so we're clear: you can take any data source in your entire back-end infrastructure that can be wrapped as an IQueryable, and then using ADO.NET Data Services, have that data source be exposed via RESTful URLs that allow for simple queries as well as data creation and update (via HTTP!) and the result sets can be exposed in JSON format or APP (Atom Publishing Protocol) format. You did know that pretty much every RSS reader knows how to read ATOM, didn't you?
I'm looking at ADO.NET Data Services to provide my own back-end infrastructure with scalable, re-usable, agile services for some seriously sweet SOA action. Its still a CTP, and I'm still implementing proofs of concept, so we'll see if I'm just being an idealist here or not.... I will be posting all of my results and sample code.
In addition to all this, there is the ADO.NET Entity Framework (which is the default data store for ADO.NET Data Services), and ASP.NET Dynamic Data which is a project that I never really got into. Basically it looks like a heaping pile of controls that take object data and auto-generate grids and tables and such without you having to do much work. The long and short of my opinion here is that every attempt I've made at using dynamic data controls has resulted in me spending more time customizing the dynamic data controls than I would have simply building my own controls or re-using stock controls with less overhead than the dynamic controls.
I've been working on some sample applications and some sample code and now that the CTP is out, I'll be posting a lot of that code here along with some opinions about the new MVC framework and ADO.NET Data Services specifically, since those two interest me the most in this release.
... Now all I need is the Silverlight 2.0 CTP!
I'm really looking forward to these new extensions. From what I've seen so
far I think there are many great features that will help simplify a lot of
the tasks I'm spending time on now.
