Customer Reviews

.NET Patterns: Architecture, Design, and Process

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

 

 

THE GOOD: The patterns in this book are very good. Useful, informative, and well explained. The author really seems to know his stuff and convey it well.

THE NO SO GOOD: Too much time is spent inadequately introducing concepts that the reader should just be sent to another book for. Ironically the author realizes this and says so before he goes forward with his useless introductory material.

THE BAD: It appears that I am the first person to read this book since it was completed. It is probably among the five most poorly edited software books I have ever seen. Simply read the fist 10 pages and you will find at least one non-sensical sentence per page. Sometimes this is as simple as an extra verb or the accidental use of "it" when the author meant "is". Other times the entire thought becomes indecipherable in the middle of a line.

This is the worst book I've ever read on programming, period. I've never taken the time to write a review before but this book is so horrible that it motivated me to look it up here and write it a poor review. I'm returning my copy. Simply put, there is very, very little useful content. Between the simple grammatical errors and the code errors I just couldn't bring myself to finish it. I read until page 59 telling myself it has to get better but it just didn't. Microsoft puts out a free book that you can download in PDF format named "Enterprise Solution Patterns using Microsoft .NET", save your money and read that. I cannot express how disappointed I was with this book.

As a person familiar with the original Go4 patterns. I think this book is definitely sub-standard. It definitely DOES NOT fit into the category of Great Pattern books (e.g Design Patterns book by Gamma et al). The Author obviously has experience in the technology and comes up with a handful of good pattern ideas however the code supporting some of these Ideas (e.g in the so called Poly Pattern)and through out the book raises more questions than answers. The conceptual explanations of what the patterns are supposed to achieve are ok to some extent but the authors coding style leaves much to be desired. The implementation of the hungarian notation in an object oriented context and his none conformance to standard OO coding standards (not even the standards laid down by microsoft the company he works for) makes poor reading for what could have been an excellent book. A simple review of the code in the book by FXcop (www.gotdotnet.com/team/fxcop/default.aspx) would support this notion. The editing of the book is also very poor. Often as you read through you wonder where a pattern begins or ends

This book is a great resource for .NET Framework developers, with patterns that are very useful and nicely solve many common .NET Framework design challenges. In particular, I like the composite "Poly Model" pattern for a flexible data access layer.

Unfortunetely, the code is full of typos and just plain errors. It is frustrating to see a piece of code querying for the number of rows effected by a query, when the count was already returned to another variable just one line above! Terrible editing has taken much pleasure out of discovering the interesting and effective patterns.

I am most disappointed in the fact that there is no downloadable code samples that show the sample implementations in their entirety, and working (which would at least force the author to make sure the code can compile).

The only reason why I am giving 3 stars is because the patterns presented are excellent overall, but this book is like reading a first draft.

I gave the book one star simply because no lower option is available.

I had high hopes this book would provide practical data tier patterns for a current project. However, the "polymodel" discussed in the book strikes me as so specialized (pertinent to atomic transaction based system - i.e. credit card authorization) that it is useless in most other areas. Even with that in mind, the concept of only storing your data as xml in a relational database is incredibly inefficient for my needs (such as data warehousing). The other point that struck me is he preceds all stored procedure names with sp_. I'm not a DBA but even I know this is a no no in Sql Server 2k. It actually slows calls to the stored procedures when you precede them with sp_.

I've not written a review before but based on the poor quality of what I've seen, I hope to save someone else the anguish.

I really don't understand the bad ratings of other reviewers. Either these reviewers didn't read the book or they are totally in love with theoretical issues on design patterns. This book shows hand on experiences - the authors shows REAL WORLD examples and illustrates how patterns are applied. I found the book very useful and it contains new interesting ideas on implementing PRACTICAL and USEFUL software applications with the .NET framework.

I have to disagree with most of the reviews here. I think the author has some good design pattern idea's. It seems like if a pattern book doesn't rehash the GOF's book for the 654654th time, its not a good pattern book. The author had some good ideas, and while most of the patterns are fairly focused to a specific problem and are not totally generic, it doesn't mean its not a good pattern idea. It's just a domain specific pattern. I think the author should have clearly specified that, but didn't and that was a mistake. He billed the book as a general user pattern book. So I game him 4 stars on that.

But, in my job I'm very focused on code performance, so I knocked him back down two stars because these patterns are pretty much useless if you are designing anything that needs high performance capabilities, like web services. Most of the book is focused on patterns that he applies to web services, but he uses stuff like XML, DataSets and Reflection to create his abstraction layers. These three things are the 3 WORST performing features of .Net. If you are creating anything that needs to run `fast', you should stay away from all three of these. The pattern that killed me was his abstract packet pattern, which used DataSets or strongly typed DataSets to pass a list of parms between functions. He even hyped this pattern up based on performance reasons. I'd have to bet the guy never ran his code through a profiler to see what the performance implications of this pattern were. He made a lot of performance claims, but never showed the numbers to prove them, which is a dangerous thing because many developers will take what an author says as word, and not test the claim for themselves.

So I think he had good ideas, but very poor choices with his implementation technology.

First, I've not got what would be considered by academic circles as a classical computer science background. I majored in marketing in college, and learned the art of programming and software design out of necessity for my Web projects to work. Needless to say, I've not had a solid background, and thus an appreciation for or acknowledgement of, design patterns within the scope of developing great software.

This book has changed all that.

This work is written in author Christian Thilmany's honest perspective and admission that much of the design of Microsoft's ambitious .NET initiative was to take from the things that made Java such a great developmental platform and allowed it become "the language of the Internet". And this rare viewpoint is well appreciated.

Being a solutions developer well versed in both Java and Microsoft platforms, this honesty lends credibility to the claim of showing how much of .NET can be attributed to roots in Java, which other authors either bash for the sake of bashing any opponent of the good folks in Redmond, don't give enough credit to, or shy away from completely. I've always seen this as unfair to the reader.

Using the approach to explaining and providing design patterns based on the similar structures used in Java programming, Thilmany shows how utilities can be assembled for use for all three major tiers of a development project. Since much of the work of design patterns is used in Java anyway, he has no reservations about explaining how work in similar fashion with .NET. And the reader is better off for it.

It's not only the code-based patterns themselves which are great, but also the method in which the author presents getting to the patterns, being examples that are repetitive, consistent, sequential and iterative, allowing the reader to condition their mind in an efficient problem-solving sequence of events: (Intent ==> Problem ==> Forces ==> Structure ==> Consequences ==> Implementation). So, it's the mental pattern of solutions development that's also discussed, and I feel, the greatest advantage to this book.

The book is also effective, I've found, for Web application architects. Typically, Web devs and those from the ilk of an ASP 3.0 background tend to shy away from topics like patterns, remoting and DCOM, as it largely was a topic rarely, if ever to be used in their work. Thilmany gives lots of helpful tips and hints in pattern design and architecture, with relevance for the Web crowd, as well as the desktop developer.

Now, being critical, I found the book's first part, in giving a primer on .NET in general and for the XML Web services model, a bit extraneous, or at least not excessive enough to warrant three full chapters. But the book from there on is gold. The patterns themselves are plentiful, well-explained and the book is beautifully written.

And you'll be a better overall developer for checking it out.

I've read a ton of tech books and this is by far, by far the worst tech book I've ever come across. The code samples are terribly edited (the code is not even indented within braces), the author insists on using obsolete Hungarian notation - a boolean can only be used in certain expressions - I don't need a 'b' to tell me that. It just creates a bunch of noise that inteferes with codes intent. Like most developers, I like to see examples to get a feel for what the author is trying to express in words. Unfortunately this book is long on verbage and way too short on examples. And the 'patterns' are kind of useless - passing a DataSet as the parm to a WebService so the interface doesn't change.. Gee thats groundbreaking - Does the author design all his classes with one execute() method so that the interface doesn't change? I have a feeling the reviewers who write glowing reports of this book are friends of the author - everyone I have spoken to about the book says the same thing I am saying here.

Update: I recently went back and gave this book another chance and I have to stick by my original review. First off, can AW learn how to format code properly? I still can't get over that Hungarian notation - just ridiculous. Also the books subtitle is Architecture, Design and Process. I'll give you the first two but where is the Process?

This more of a how-to book than a patterns book. The author tries hard to make this a patterns book but its not. Its not a bad book.. just not what I expected from it.