Where is the holistic vision?

Microsoft is needs a holistic view of their platforms and development tools. I didn't see that this week, I doubt any of us will.

What I did see was 7 data access techniques in various stages of ready now, coming soon, and coming much later:

  • Use a DataAdapter to issue SQL  or stored procedures. Useful for working with a DataSet and doing optimistic updates.
  • Use a DataReader to issue a SELECT or stored procedure to walk through rows 1 at a time. Used for fast streaming of read only data.
  • SqlDataSources. From what I can tell, this is a terrible thing. I've seen this in two places so I'm not sure they are the same. The first demo I saw of this it was just called a “Data Source“ It was in a windows forms application and it looks  like a typed dataset (and in fact is/uses them) but it also embeds SQL queries (and updates, inserts and deletes) into the actual typed dataset. But I use datasets through the various tiers of my application from UI to data access and I don't want this marshaled throughout the application. I talked to Paul Yuknewicz from the VB team about this. I told him it would be okay in the design time to do this - but you have to split these out into two classes. He said I could, but he couldn't show me. He said the typed data set and the data access classes could be in separate namespaces. When I told him I needed them in separately assemblies because my datasets go down to the win forms client, but the data access sits in my middle tier and hits the database. He took this as a good feature request, but he didn't give me a good feeling about it. I mentioned this to another guy on the Data team and he said that these Data Sources would not be for me. I suppose if you're building a dog house, it doesn't have to be well architected like a sky scraper. Unfortunately I've had to do many renovations of dog houses in the past.
  • You can now embed some of the logic you'd do post retrieval to massage some data into the database. Yes, create a C# stored proc and return the data that way. You probably want to do this if the processing reduces the amount of ASCII (or the visibility - plain text - no encryption) to be sent along the wire.
  • SQLXML - not new but improved and gaining momentum. Can you say new language to learn? XQuery, XPath. This is nice if the data you deal with outside of the database is in XML. Also good for doing master/detail updates in 1 round trip. I like this.
  • ObjectSpaces. I saw a preview of this at PDC 2 years ago. I'm going to another session to learn more details in an hour. It's changed since then but the message is the same. It's an Object to Relational mapping scheme. You define how your tables relate to your objects - and then you merrily use your objects and ObjectSpaces figures out the SQL to send to the database. Why would you do this? Well if your app embeds a lot of business logic in your objects - which it should damn it. This technique lacks SQL fidelity and you have little direct control over the SQL emitted. Hmm. If I don't know what SQL will be issued how will I determine the best indices? How does the SQL Server team feel about this? I've already heard from Michael Pizzo that you can't expect the same performance as native SQL.
  • WinFS. Longhorn includes a new file system. My interpretation is that it's less of a file system and more of an intermediate object model that sits over top of NTFS and the next version of SQL. WinFS let's you view your SQL data as files. A record is a file. Not all files become records though. (I can hear DBAs everywhere sighing). The idea here is to “give users excellent windows experiences“ by getting data out of the silos of applications and bringing it to the shell to be integrated between applications the way users want it. I like the idea in theory but the security aspects scare me a bit. The nice thing is that this is coming in Longhorn - a long time from now so we have time to think about this more...and for MS to try and get it right. You can bind controls in your forms to properties on files (which are records - so those are just columns). Where is the business logic in that tier? Welcome back client server. Not sure how this all works on a LAN.

I was also saw at least 3 user interface models:

  • Traditional Smart Client Window Forms. These don't' change much in Whidbey.
  • ASP.NET Web Forms. Changing a bit. Still HTML coded into an aspx file.
  • Avalon XAML Forms. See my previous post about this. The key point is that it attempts to bring the benefits of Web Forms to Windows Forms and vice versa.

Let's not get into Pocket PC, Smart Phones, WML, Tablet Ink or Media Center. That would make this blog more ridiculous than it already is. Suffice it say that each of these 3 user interfaces all have their own databinding techniques and they are all different. I saw some of the ASP.NET Whidbey two-way databinding today and its nothing like WinForms binding. It's like that team never talks to the windows team. Sigh.

What I didn't see was anything about COM+, Enterprise Services. Where the hell was COM+. Does that all disappear with Indigo? Indigo is only supposed to be a communication platform right?

I guess it's my job as an architectural consultant to value each of these technologies, how they fit together ultimately - and a road map for doing something useful today - that will be useful tomorrow. Nobody at Microsoft has done this yet.

The scary thing is that it seems like all these teams are working in silos and not talking to each other enough. Seems to be a theme. Don't get me wrong, the are doing fabulous stuff but everybody has a different way of doing things. It seems like they spend lots of time developing their technology but not enough time building real applications that sit on top of them.

The good news is that its early for a lot of this stuff and lots of time to fix it and get it right. A lot of Microsoft guys were seeing some of this stuff for the first time themselves.

I suspect that the MSDN Prescriptive Architecture Group has some work cut out for them.

Longhorn, Avalon and XAML oh my.

Yesterday I spent all my time at Longhorn presentations....for the most part. I got a chance to look a close look at XAML.

XAML does for smart client windows forms apps what aspx/HTML does to web apps: separates the UI from the rest of your app. In the wake of infopath, I've told more than one person that I didn't think traditional developers would be coding user interface 5 years from now. XAML makes it a lot easier for that to become true.

But XAML is more. Sure you can mark up your form with XML. But it can be compiled into BAML. Binary XAML. You don't have to use XAML to code up your forms, you can still use the current Windows Forms designer than puts your controls into .NET Code in the “Designer Generated Code” region of your form class. Both techniques get compiled and are the performance equivalents. That's cool. You can further compile (or is it link?) BAML into assemblies.

XAML has 2 (or 3) rendering modes. Fixed Format is like windows forms now. Also like Grid Layout in ASP.NET. You scroll around and stretch stuff - but nothing moves. Flow Format is more like traditional flowing HTML. You resize your browser and stuff changes. The rendering agent takes care of paging so the # of pages changes automagically as you resize. You can even click on the scroll bar to get thumbnail views of the next pages in the whole document.

Adaptive Flow is cool. Imagine a 16:9 wide screen and you resize your document to be full screen. It's tough to read a line that long. They've though of everything. When a line becomes too long to read, the rendering engine flips to the display to 2 columns like a newspaper or DTP style document. Makes it so nice and you can see it happen quickly as you resize a form - bam - two columns.

XAML makes skinning pretty easy. In fact in the “Being a good Windows Citizen” presentation, the Windows User Experience team talked about a technique for designing your UI that MS uses and recommends that we all do it. Create 2 or 3 fictional users for your application whose profiles are based on real or anecdotal evidence. Give them names. Give them photos. When you need to make a decision about how your UI should look or the app should work - ask yourself: How would Toby like this screen? How about Jeff? Ms has 8 fictional people that encompasses the full spectrum of their core windows & office products. Skinning your app is sometimes the only way to create a UI that will satisfy everybody - give them each their own. Not only is this possible with XAML, it can be done after the initial compile of your application and you can deploy BAML after initial release much like localized satellite assemblies. Way cool - so long as you design for this from the get go.

Another cool thing about longhorn is that the UI is all vector based. So you can do things like rotate your buttons and text boxes etc. Pretty cool, not very useful. Being able to zoom in on a part of your text though and still have a pretty (not aliased) image is wonderful. It demonstrates the power of the new graphics subsystem and the dependency on graphics cards in Longhorn. It's fast. The new graphics subsystem is rebuilt from the ground up to provide very fast. It needs to. Resolutions are getting bigger and bigger, and being able to scale a traditional UI to make it bigger is important given the predicted growth of screen sizes. It seems like more of a bell or whistle at this point, but it's going to totally change the user experience.

Data binding is now built into the OS. You can bind to files on your WinFs hard drive. A file can have meta data defined by a schema and any of that information is fair game to be bound into your apps. More to come on this. It's just too far out for me to “make it real” at this point. Data binding is one of those things you just have to get into when you need it. But it looks good.

I thought it was kind of goofy that during the key  note, all developer demos  for Longhorn and Avalon were done with Emacs, Slickedit and VIM. Then I realized they had to be. There is no Visual Studio for Avalon yet. You can still get VS.NET any version to edit the class files, but it's no full developer experience for Longhorn/Avalon. There is no WYSIWYG XAML editor yet.

Get ready to design your screens in FrontPage - Ahhhhh!

MS Professional Developers Conference...

...here we come.

Myself and fellow ObjectSharpies DennisLee and DaveLloyd are heading out Saturday morning for the PDC in L.A. Stay tuned for our perspectives on Whidbey (essentially .NET 2.0), Yukon (SQL Server 2004?), and Longhorn (Windows 2005?). Key pieces of technology I'll be researching are Indigo (new web services framework) and Avalon (new windows forms framework).

I'm also looking forward to seeing MSBuild and trying to understand how it will compare, compete or compliment NAnt. I still don't see anything about the next version of Visual Source Safe - what's up with that?

If you are in town, look me up and I'll buy you a beer.