Customer Reviews

Pro ADO.NET with VB .NET 1.1

5 star:		(3)
4 star:		(2)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

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.

I was quite impressed with both the breadth and depth of material that was covered in this book of ADO.NET with VB.NET 1.1. I work alot with DataSets and XML and not only was the traditional ADO.NET processes of retrieving and storing data with data readers and data adapters covered, but then goes head first into XML and datasets. It is actually not that easy to find some of this information on the internet and in such a well explained manner, thus this book is well worth its wait.
These are not general approach text, but code heavy examples.
A good understanding of ADO.NET would be appropriate before taking on this book as while it does a good job of explaining and providing examples, the pace is fairly rapid and is really targeted to the professional looking to up the skill level in ADO.NET. I have become a C# coder for the most part, but as you all know, changing the VB syntax to curly brackets is not that bad and thus this book serves the C# coder as well.

I would certainly recommend this book as a good example/reference/code snippets for ADO.NET 1.1.
Look for the ADO.NET 2.0 book as well.

Pro ADO.NET with VB.NET 1.1

I've been involved deeply with DB access applications for the last 5 years, and I've read many books on the subject. I've read some that were bad, and I've read some that were amazing. This book is definitely a good one.

Note that this not intended to be a full reference on the intricacies of the object model, but more of a "this is what it can do, and here's a practical example" type reference.

Our author does a great job of introducing the subject. This is intended to be book for someone with some experience; it is not a beginner's book. Mr. Malik writes the book with the perfect voice for his audience. I also found the inclusion of references to prior versions of ADO to be most useful, too. He even provides specific instances when it would be better to use prior (non-.net) versions of ADO since the functionality either doesn't exist, or works much better. This realistic approach to ADO.Net's abilities is consistent throughout the book.

The book most notably does a great job of "selling" the data reader object in .Net. This is an exciting, very powerful read-only connection that can be used for variety of purposes. Mr. Malik gives many useful examples (e.g., reporting) where this is *much* faster than standard methods. He demonstrates how to use the GetSchemaTable, and how to bind it to a data grid; a very nice way to get this information out of the database.

The code examples were very specific and addressed their topics very well; not a lot of fluff that serves little purpose. I find that shorter, more direct code snippets like these are more useful. Ideally, a code example should fit on one page, if at all possible.

I felt the chapter on creating your own data provider was interesting, but might have been a bit too advanced for most readers of this particular book. I also thought this was covered a little quickly, since it does only make up one chapter; I suspect an entire book could be written on the subject. It wasn't a bad idea to include it, but it was perhaps a bit too much icing on an otherwise very good cake.

So, if you are looking for a "down and dirty" intermediate practical usage reference, you need not look much farther than this.

I had a very narrow vision of what ADO.NET was until I read this book. ADO.NET is more than just DataSets and DataAdapters. It also involves XML, Data Services and Web Services. This book covers it all and more!

All the basics are covered. Chapters 1 through 5 explain Data Readers, DataSets (Typed and UnTyped) , Data Adapters and Data Schemas. I was impressed with the depth covered on each of these subjects.

What I didn't expect was the XML coverage. Chapter 6 covers everything you need to know about XML and how to use XML with DataSets.

Chapters 7 through 9 explain Constraints, Relations, Views, Transactions, and Mapping.

Data Services and Web Services each had full chapter. This was an unexpected bonus.

Performance and Security is covered by including optimizing, connection pooling message queuing, and basic security concerns. I always wondered what MSMQ was and now I know!

Also covered where InterOp and Migration from ADO.

The last chapter walks you through creating a MSMQ custom data provider. Very cool!

This book will make a fantastic resource book. This is definitely a must have for any level programmer!

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.