How do you feel about the VS.NET Query Designer

The VS Data Team wants your input. Head over here. (BTW, don't you love these surveys? They're the best and tell me that MS really cares about what we think).

Layered Design and DataSets for Dummies

Scott Hanselman does a nice 30 second intro into layered design. If any of this is new to you, run quickly to read this.

Scott does a quick bash at Datasets (although doesn't say why) and in my new role as DataSet boy I have to disagree with him and evangelize how simple datasets can make a lot of the code written by the typical programmer: CRUD stuff for example. He even mentions “Adapter“ in describing a data access layer - come on, use the DataAdapter - don't be afraid. In general, if anybody tells you to never do something, you need to question that a bit and dig into the reasons why a technology exists. Of course things may just end up being rude and the answer is indeed never - but always try and get the why.

We've been running a developer contest at the end of some of our training courses (the big 3 week immersion ones). The competition has developers build a solution build on a services oriented architecture which includes smart client, web services, enterprise services/com+ and of course data access. It's only a 1 day event, but the teams are built up of 5-6 people each. Inevitably, if one team decides to use datasets/dataadapters and the other team doesn't, the team that choose the dataset wins. This competition isn't judged or skewed for datasets by any means. But inevitably this is the thing that gives the other team more time to work on the interesting pieces of the application (like business logic: features and functions).

I over heard Harry Pierson tell a customer last week that they shouldn't use datasets in a web service because they aren't compatible with non .NET platforms. This isn't true. A dataset is just XML when you return it out of a dataset. And you probably more control over the format that is generated via the XSD than most people realize. If you want a child table nested, no problem. You want attributes instead of elements, no problem. You want some columns elements and others attributes, no problem. You want/don't want embedded schema, no problem. You don't want the diffgram, no problem. Somebody in the J2EE world has actually gone to the extent of creating a similar type of base object in Java that can deserialize the dataset in most of it's glory. (Link to come - can't find it right now).

In February I posted a “Benefits of Datasets vs. Custom Entities“ which has generated some excellent feedback. It's still in my plans to write the opposite article - when Customer Entities are better than Datasets but I'm still looking for the best template or example entity. Everyone somebody has sent me to date is somewhat lacking. To be fair, I end up always comparing them to a dataset. The things typically missing out of a custom entity are the ability to deal with Null values and the ability to track original values for the purposes of optimistic concurrency. The answer to the question of “When to use a Custom Entity over a Dataset?“ is of course when you don't need all the stuff provided for you by a dataset. So is that typically when you don't care about Null Values or Optimistic Concurrency? Perhaps. But I know there is more to it than that.

I will say there is some crummy binary serialization in the dataset (it's really XML). This is really a problem if you are doing some custom serialization or need to do some .NET remoting. But you can change the way they are serialized (and indeed it's changed in Whidbey). There are some good examples here, here, here, here, here and here.

I'm working on an article making the cases for the custom entity, but in the meantime, datasets represent a good design pattern for entities that is easy and quick to implement by the average developer - and scalable too.

TechEd (Day 3): Hands On Lab Manuals downloads available to the public

No need to have a TechEd commnet password. You can download ALL the pdf's for the plethora of topics. Some good stuff to see how the newly announced stuff (Team System, etc.) works.

Update These links are broken, give this a try: http://www.msteched.com/TechEdLabManuals.aspx

TechEd (Day -1): ObjectSpaces = Longhorn, 3rd time charm?

It was bumped from The initial 1.0 release, and then as of last PDC slated for Whidbey. Now it looks like we'll have to wait until Longhorn.

It's not all bad news however. ObjectSpaces is being re-orged into the WinFs file system. When you think about there is an awful lot of correlation to those technologies. I'm sure it's not terribly unrelated to the fact that the Microsoft Business Framework(MBF) that was to build on ObjectSpaces was also pushed off to Longhorn/Orcas. MBF is also to rely on an orchestration engine (Biztalk light?) features going into Longhorn so it all makes sense.

Some people will be disappointed - but this is a good rationalization of the way too many data access/storage visions within Microsoft. Both of these technologies have a common thread about objects/applications and data and breaking down the wall. Sure, MS could have released ObjectSpaces first, but do we really need that legacy and all the effort attached to YADAA (yet another data access api.

Microsoft has taken a lot of criticism (including from me) about the seemingly constant churn of all things data. So this is a good sign that MS is not going to do things, just be cause they can, but do them right. Just ask a Java developer what they think of EJB's. It's important to get it right

http://msdn.microsoft.com/data/

TechEd (Day -1): Pieces of ADO.NET 2.0 not going to make Whidbey

Highlights in this exchange of newsgroup posts...

  • Paging is cut
  • Server cursors cut (SqlResultSet class)
  • Async Open is cut, but not excute
  • SqlDataTable class cut (Good - that was a bad design pattern to propogate)
  • Command sets are cut, but you can still do batch DataAdapter updates,

http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slcid=us

More to come, stay tuned.

Security for Developers

Why is that you can't plug a fridge into your house until it's been CSA or FCC approved, and that you have to have a licensed electrician install or at least review any modifications to the wiring in your house plugged into the grid - but any yahoo can build a piece of software and install it on their home computer connected to the internet for the world to hack into? Before I make a case that developers should be forced to do some security training or pass some certification....we have to keep in mind that most of the time the software sitting on somebody's home computer that is getting hacked into is Microsoft's. This is largely due to the size of the huge target on their back. What you think Linux is really more secure? What do you think is easier to hack into? It's easier to hack into something when you have the source code.

So, having said all that, there are changes coming for Microsoft developers in the security space:

  • Microsoft is turfing a few of the existing security training offerings. These include the Microsoft Security Clinic (2800) and Security Seminar for Developers (2805).
  • There is a new security course being developed: Developing Secure Applications (2840) and also a MS Press Training Kit both of which I'll be reviewing during their development.
  • Related to the new course and training kit, there is a new security exam for developer which unfortunately because of timing is only an MCAD/MCSD/MCDBA elective (not a required element - sigh). There are 2 versions - 1 for VB and 1 for C#. I guess they figure C++ and J# developers already write secure code. These are going into beta at the end of next month and I'll be auditing the C# version.
    71-330 Implementing Security for Applications with Visual Basic .NET
    71-340 Implementing Security for Applications with Visual C# .NET

I'm a little torn over this direction. Part of me says that security is so important, it needs to be covered in every MS Training course. To a certain extent that is already true, but I think they could go deeper. When I teach a windows, web or services course, I try to go deep on security. Sometimes you can go to far. Some pieces of security are more relevant to the type of application you are building, while other security issues are common regardless of the application architecture. Obviously we don't want to repeat a lot of content in each course - sometimes that is unavoidable. The other issue is that there is a lot to know about security and frankly I don't think every developer can master all of this. So teams need to dedicate a security architecture role on their project. For these folks - then yes I think it makes sense to have specific and deep training and certification for them. I think MS could probably do better than a single exam “elective”. How about an MCSD.NET+Security designation? MCDBA+Security as well - although you could argue that MCDBA's should be forced to have this security. Perhaps that will happen in the wake of Yukon - although I've heard no rumblings of creating Whidbey or Yukon flavours of exams or certifications at this point.

Our industry and profession needs to take a leadership role and be proactive in accepting responsibility and accountability for the important issue of security. We need to move our discipline to a higher level. I'm not convinced it has to be government that steps up to this place. Governments should only do what we can't do for ourself. Microsoft seems to be taking an increasingly proactive role on these security issues. It will be interesting to see how this pays off in 2-3 years from now.

Whidbey and Yukon names and dates tighten up

So I've heard that Yukon (Sql Server) and Whidbey (.NET 2.0?) are being now committed for “the first half of 2005”.

Furthermore, it can be confirmed that the names Sql Server 2005 and Visual Studio 2005 are the official names. Officially, I believe this is a 6 month slip. http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx. That's not too bad in the grand scheme of things...and of course, we all want to wait as long as it takes to get it right.

.NET 2.0 Whidbey Presentation in Toronto

On December 9th, myself and Dave Lloyd will present an in depth sneak peak of the next release of .NET: Visual Studio .NET 2.0 (code-named "Whidbey"). This should be a really fun presentation but seating is pretty limited. Adam Gallant from Microsoft is going to come by and also demo Longhorn and Avalon. He's getting daily builds so hopefully he'll show us some cool stuff that wasn't in the PDC build and is maybe even newer than some of the stuff they showed us at PDC. Hope to see some of you there.

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.

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.