Rating: 
Summary: An Brilliant Contribution to our Field - Read 2-3 Times
Review: Amazon Buyer,
The negative reviews puzzle me completely! I can only imagine the readers were expecting something different or didn't read the same book I did <grin>. Or do not build enterprise applications. I don't mean to say anything negative about my professional associates on Amazon, I just think (as a person addicted to reading <grin>) that this book is absolutely, positively fantastic.
There are so many nuggets of gold in this book. ANY serious .NET architect should have this publication on their book shelf.
There are about 5 more core books, many by Addison Wesley, a company that in my mind is leading the pack in Software Engineering work. Just my 2 cents.
If you would like my reading list please email as I am always happy to help those that are seeking a path. If I know your goals, I can probably certainly give you a set of books to get you to your goal. And again, I do disagree with the negative reviews but I do not mean any disrespect. Just friendly disagreement.
Kind Regards,
Damon Carr, CEO and Chief Technologist
agilefactor
www.agilefactor.com
Rating: 
Summary: A Good Reference of Standard Patterns
Review: As .NET develops, a question naturally arises to developers who use it, or are pondering doing so. What patterns exist in it? Given it as a development platform, can a set of useful patterns be extracted, akin to those in J2EE for example.Thilmany answers yet. He divides these into 3 groups - for presentation, middle and persistence tier. You may be familiar with these under the names of client, business logic and database layers. Within each group, if you have experience in another environment, there will again be some familiar patterns. For example, he describes something he calls "Abstract Cache". This appears to be a useful generalisation of the caching/pooling you might see in some J2EE containers. Actually, if you look again at this, it is really an extension of java's Hashtable. In some ways more restrictive, because here the key is a String, whereas the Hashtable can have an arbitrary object reference as key. In other ways, more general, because when you insert an object into an Abstract Cache, you can set an expiration time. [Of course, in java this would be a simple extension of Hashtable.] Well, that is just one instance of a .NET pattern. But the comparision with java illustrates one of his points. Several of the patterns are independent of any environment. These are especially valuable to you, as you can reapply them as new technologies emerge. I do have one quibble. He compares .NET favourably with J2EE. For example, he points out, correctly, that, for example, you often cannot go from IBM's Websphere to BEA's WebLogic without some recoding, due to each J2EE vendor having proprietary extensions. But if you migrate between J2EE vendors, you rarely have to recode all your application. Usually only some small part, albeit possibly a crucial part. His point is quite valid. But he does not take the next step, by applying this criterion to .NET itself. No other major vendor supports .NET. If you develop within it, and want to leave, you are staring at possibly a huge recoding effort. By the very logic with which he criticises J2EE.
Rating: 
Summary: Overall Not a very good book
Review: 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
Rating:
Summary: A book for the working designer
Review: Finally a practical design book -- with code. Very unique. At last, a book for both architects, and developers of .NET. Thilmany really speaks to level that is practical and backs up the rhetoric with architecture patterns that can actually be used in REAL LIFE! This book employs the whole think-like-a-fundamentalist-but-design-like-a-technician strategy, revealing how to devise critical, complex designs for use in the real world. This is something I'm going to recommend to my team (all 15 of us) and hope we get a second edition soon. This book fills in the gaps where the trade publications leave off. Best...bucks I've spent yet on .NET so far.
Rating:
Summary: Great pattern resource, cool approach; U can skip the intro
Review: 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.
Rating:
Summary: The Worst to come From AW
Review: 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.
Rating:
Summary: One of the few books I've ever returned
Review: 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.
Rating:
Summary: One of the few books I've ever returned
Review: 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.
Rating:
Summary: Maybe not the worst tech book ever... but close
Review: I have to agree with the previous reviewer about the low quality of the content in this book. It's kind of absurd to mention .NET and patterns in the same breath, since .NET's whole infrastructure is years behind the rest of the world in terms of supporting design patterns, and Microsoft itself just doesn't seem to get them as a concept. (Have they ever heard of MVC, for instance?) The Gang of Four book and many others provide real documentation about what patterns really are and how they facilitate good application design. But this book is mostly fluff. I'd heartily recommend Core J2EE Patterns over this book as an introduction to patterns in the web application framework space. Yes, that book is also tilted towards a particular platform, but it gives practical ideas about real patterns as used in serious web applications.
Rating: 
Summary: Good ideas but...
Review: 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.
| 
