.NET Books
I've been considering what the best books for bringing someone up to speed on .NET who is a programmer already (though not necessarily VB) might be. Ideas?
Yukon Doomed?
Don't get me wrong, I enjoy working with SQL Server, but I think Microsoft has made a strategic mistake with Yukon.SQL Server needs to support truly Shared Nothing clustering. In a world where Microsoft is espousing the need for Web Services, where they are pushing for a de-centralization of software from any given computer, to multiple computers at any distance, their database will have to handle the expectations of such a world.If I try to sell a piece of software that runs on remote servers via a variety of clients in the field (Web, WAP, Winform, etc) then my client will expect, reasonably or not, almost no downtime on the application. That means my database must be robust enough to handle small hardware problems without stopping. Oracle has had this going for a while now, you can cluster Oracle servers, and then take just 1 of them off-line to work with, the rest will pick up the load.We need to get Scale-Out not just Scale-Up for SQL Server, or you're just cruising for problems.
4 Teirs to build the app...
and 1 data access component (dac) to rule them all, 1 dac to find them, 1 dac to bring them all and in the darkness bind them. In the land of SQL Server, where the Yukon lies.Tim Rayburnwith apologies to J.R.R. TolkeinI've spent some time over the last several days reviewing some of the “best practices” which I've developed for Visual Basic 6 in the light of the Visual Basic.NET and the .NET Framework in general. Here are some of the thoughts I am having:Data Access Components - Several times over the years I've heard the arguement for a data access model which has 1 component to handle running SQL against an RDBMS, with project components developed which reference that component and offer up that data to the “business objects”. The problem has been that recordsets just are not meant to handle that type of environment. But ADO.NET on the other hand, seems to have this taken care of, in spades. This model is nearly perfect for the world of .NET, as you right a singular class to work with the most efficient DataAdapter for your RDBMS. Then your project specific data access components are written to use schema'd datasets, which will ease the development of the business objects.Gone are the days, of Option Explicit - Option Strict is the only reasonable way to go. Yes, VB developers will need to learn how to actually declare variables of they type you need, but it also can get rid of alot of 'mystery' bugs arising from assigning a Long into a Variant when you expect it to be a String, etc.Likewise gone is On Error - Try ... Catch ... Finally. Say it three times, it's just not that hard. I know, I can hear the real world developers whining about having perfected their cleanup routines to use On Error and how well it is serving them. Have you looked at the glory which is Try ...Catch ... Catch ... Catch ... Catch ... Finally? I'll post some examples of this next week. Error checking will never be the same.Web Services - I know Microsoft is trying to 'down talk' web services because it frightens people out there who are simply doing Client/Server apps, etc. Trust me when I say this, every Class you right should implement itself as a Web Service as well. Why? Because you might just need it eventually. Because when your boss asks if you could allow him to interface with your application from his PDA or cell-phone, you'll just smile and say, “Of course, we'll just develop another presentation layer for them.” And you won't be lieing through your teeth when you do.Hardly a complete list, but it is some initial thoughts.