Pro ADO.NET with VB .NET 1.1

Rating:
Summary: Too good for words but I'll try
Review: As many of you probably have figured out, ADO.NET is probably my favorite piece of the .NET Framework. While many other facets of the framework were improvements over past paradigms, ADO.NET was unquestionably a 'differen't technology. Well, until now, I thought there were two must have books on ADO.NET, David Sceppa's ADO.NET Core Reference and Bill Vaughn's ADO.NET & ADO Examples and Best Practices in (VB.NET or C#). Now, there's a third. A while back, APress bought out a bunch of Wrox titles and redid them the Apress way. Every single one that I've gone through so far has been a DRAMATIC improvement over the original version and it looks like it's the case with this one too.

First off, some background information on "why" ADO.NET is such an important topic that it warrants buying at least 3 books on it. In the old days, you used to have a connected metaphor when you were using most data access technologies. For instance, previous versions of ADO required a persistent connection to a database to be of much use. But ADO.NET changed that in a fundamental way. Now, you can deal with database access in a Service Oriented way. You can retrieve data from a Text file, send it to a web service, then to an Oracle database then to a SQL Server database and you can wrap the whole thing in a transaction. You can easily build a service facade that interacts with a data access layer - if you want to change your back end you can simply change the data access layer and not touch your business objects. Distributed transactions, transactions that span multiple databases or providers are now a snap. You can grab data from a Web Service or a SQL Server database and never be able to tell where it came from and use virtually identical methods to retrieve and manipulate the data. And while there are so many areas that are greatly improved, new complications pop up. The old way of dealing with concurrency has changed and is somewhat more complicated for instance. On the whole, things are exponentially easier, particularly in the realm in Enterprise scenarios but the additional power means that you have to Think thing through a lot more. And the reason this book is so good is because 1) It's technologically correct (which was something quite rare in old Wrox books) 2) Because the more complex areas of ADO.NET are covered and covered quite well.

Including tables and indexes, the book is just over 600 pages. The back cover even features a picture of Sahil (looking very serious for someone as lively as him) on the back. I think everyone can agree that wrox's brillian idea of putting 10 people's faces on the cover of each book was a bit challenged as far as marketing goes.

Chapters I-IV are the elementary stuff - the what, why etc of ADO.NET and a brief run through on how the core objects work. That's obligatory in any book. After that it gets fun though, and fun quickly. If you don't understand XML, and understand it pretty well, then you don't understand ADO.NET. Chapters 5 & 6 discuss XML and its role in ADO.NET and on a scale of 1-10, I'd have to give them a solid 8. That's a really high number considering it spans only two chapters. Concise, thorough, to the point and interesting are three words that come to mind when descrbing those two chapters. When I say thoroug, I don't mean that 2 chapters exhaustively discuss XML -- that's the subject of MANY books. But by the time you are done, you will have a good enough understanding of how XML relates to ADO.NET and how to use it that you won't be a danger to yourself anymore.

Chapter 7, Constraints, Relations and Views is definintely one of the money chapters. When I was moving to Greenville, I had to take some time off from the newsgroups and when I came back, some guy named Sahil Malik was posting up a storm and unlike a lot of newcommers, his answers were rock solid. There's no doubt he has a strong understanding of the typical pitfalls of most developers learning ADO.NET and he gets you right through those. Way too many people think that DataAdapter.Fill is all you need to know and they invariably end up writing a LOT of code and doing a lot of Goofy stuff just because they don't know that there are existing objects that will do the job for them or they don't know how to use them. I personally have encountered a situation where 'professional' developers were called on to build a component which made extensive use of Typed Datasets. Mind you that there's a team of 5 'experienced' .NET Developers that were working on this. Well, one of the requirements was that the typed datasets needed to be filled (obviously) from a database. Their solution? Pass an Untyped dataset to the DALC, retrieve the data and manually loop through the returned dataset, table by table, and add the data to the typed dataset. Not surprisingly the code had a little disclaimer "We didn't implement the update code yet, we're having some trouble with it". This is so unbelievably poor that if it were done in the medical arena, some lawyer would be rich off of it. But this isn't atypical by any means. However if they had any understanding of Rowstate for instance, it's doubtful such a silly approach would have ever entered their minds. Similarly, they had some bad logic in their select statements and ended up pulling back data that, when copied to the typed dataset, violated the integrity constraints on the dataset. So they simply used a Try/Catch and at the exception. It filled correctly, but think of the unnecessary overhead associated with this. Think of all of the extra code necessary to do it this way. If they had read Chapter 7 of this book, I can assure you they would have known enough to know that this approach was a recipe for disaster and after reading Chapter 5, they would have known how to use a Typed dataset correctly. (Note to all new ADO.NET Programmers: Just because you see "DataSet" in the parameter list on DataAdapter.Fill() - typed dataset ARE datasets so you can safely pass them in. They obviously didn't understand inheritance but that's a different story. In addition this chapter discusses one of my favorite objects, the DataView

Chapter 8 delves into transactions and there's plenty of good stuff in here. Using a simple transaction is, well, simple. Using distributed transactions is another story (at least until ADO.NET 2.0 and the TransactionScope arrive). Well, in all honesty, in most enterprise scenarios, simple transactions aren't going to cut it for you. He goes through some more complex transaction examples and does a darned good job. (Obviously using COM+ and distributed transactions couldn't possibly be discussed fully in one chapter, but there's still a LOT to work with here).

Chapter 9 deals with Mapping. Again, it's a good discussion but there's only so much you can do with Mapping. However if the people above read this chapter before coding there 'solution' , I doubt they would have made the mistakes they did either. Mapping is a sleeper of a subject but important nonetheless. The Data Adpater Configuration wizard uses it extensively in the code it generates, and you'd be well advised to understand what it does and how it works. A lot of new developers use the wizard without understanding how it works - which is NEVER a good thing. David Sceppa used great Stevie Wonder lyrics to drive this point home "When you believe in things that you don't understand, Then you suffer, Superstition ain't the way" Wonder
Chapters 10-14 are the Advanced issues covering things like web services, security, performance etc. I personally have read a lot on the subjects but I still found them interesting. He does a little more on XML processing and SQL Server/XML in particular which is definitely good stuff to say the least. I'm not really devling into the details but that's not because it's not well covered - it's simply that a lot of that information is pretty technical and it's hard to get into the details of it without getting too technical. Besides, I want to save room for Chapter 15.

Without a doubt this is the HOME run of the book. Sahil pulled a rabbit out of a hat with this one. He goes through the process of making your own custom ADO.NET Provider. In so doing, he discusses the interfaces that each of the core objects are built on and what they do. You simply can not get out of this chapter without having a really firm grip on what ADO.NET is all about. In all of the books that I've read, this chapter has to be one of my favorites, hands down. So what provider does he build? A MessageQueue provider. Combining a killer topic like MessageQueuing with building a provider was nothing short of brilliant. He could have wrapped things up 100 different ways, none of which would have come close to this on pure coolness. Don't know about MSMQ or MSMQT yet? Well, get with the program - the stuff is pure gold and I can just about guarantee that you will find a great place to use it. Combining the two subjects was just great. I had thought about writing an article on building a provider using the File System but this is 100 times cooler than that idea. It's technical, complex and very in depth - and the icing on a very good cake.
All in all this is one of my favorite books - mainly because I love ADO.NET coupled with the fact that Sahil just straight up kicked a33 in it. Totally interesting. Tons of 'real world' stuff. No detectable fluff. If you want to learn ADO.NET correctly or want to understand it better - I can vouch for Suhil's guru credentials in both writing and ADO.NET! You won't be disappointed.


Rating:
Summary: built a Web Service using ADO
Review: The many authors of this book show how to use ADO if you are coding in a .NET environment, and need to access a database. The authors chose to have the example code in VB.NET 1.1. Though they might equally well have used examples in C#. Perhaps they felt that VB has a broader allure?

Conceptually, the role of ADO is simple. It is a layer between your application and the database. It gives you standard ways to read and write data, largely independent of the actual database. Java programmers will recognise this as similar to JDBC drivers. But while the concept is simple, the book shows that the details of how to use it from your application can be nontrivial.

To some of you, who are interested in developing Web Services, there is an entire chapter devoted to showing how you can do this. Where the Web Service has a database and its access of this database is mediated by ADO. The chapter tells how to build a Web Service from scratch, using ADO. A nice comprehensive approach that you should be able to easily adapt to a specific Web Service of your design.