Customer Reviews

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)

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

 

 

If you haven't bought this book yet, you really should. The first edition has been an invaluable asset to me on a number of past projects, and the second edition is even better with sections on newer language and framework features such as Linq and extension methods.

I've seen, read, and even written a few standards documents in my time as a professional programmer, and I think this book is the last one I'll be needing. The format of the book is one I always enjoyed, with the guidance interspersed with comments from the "peanut gallery" of Microsoft architects. These asides give you a lot of insight into the "why"s, something which a lot of standards documents are missing (I'm talking about YOU, IDesign). It's one thing to be told to do something in a particular way, but it's a lot better when you are told why. Simple coding patterns that I wouldn't have given a second thought to have turned out to have a great impact on other aspects of my code once they were explained.

The basics are covered, such as naming and formatting standards, but the book goes much further with sections about when and how to use certain interfaces, and provides some brief explanations of common design patterns as they relate to the .net framework. I'm not talking about "Visitor" or "Model View Presenter" here, I'm talking about "IDisposable"... muuuch lower level stuff.

Basically, this book isn't just about what you ought to be doing, it's about explaining why Microsoft did what they did in the .net framework. It's refreshing at times in the book to find a discussion about how something was a bad choice in retrospect, or how the framework designers wished they had done something differently knowing then what they know now. I feel a lot better about my own changes of mind, and less like an amateur for not having seen the eventual solution in the beginning. After reading it, I'm more comfortable that I've made the right career decision to stick with this programming stuff.

Another great asset included with this book is the DVD. It's full of training sessions and example API specifications. One of the first things I did with the previous edition was to convert all the videos to play on my Zune, and spent the next few weeks watching through them whenever I got the chance. I probably won't watch them all over again, since I think they're the same videos, but they're definitely worth the watching.

Also if you're thinking on developing a framework on any Object Oriented language, this is your book, it covers all the guidelines that makes a framework usable and powerful.

This book is a must read for .Net developers. I highly recommend it. I'm sure everyone will be able expand on something they didn't know with this book. I would have liked to have seen a electronic copy of the Coding Style Conventions and a summary of all the Do, Consider, Do Not for each chapter to use as a quick reference guide.

I build a product for users that has a large and complicated API. Over the years the API has grown sort of as the users needed it, and as the developers working on it thought of things. As a result you end up with one designers version of a variable called IsSet and another in another class called Active. The little things in an API (like consistent naming) make a big difference to users. So I was interested when I saw this book was from the Dot Net team.

The book is a series of guidelines, and then callouts from various contributors to the framework of why they like or dislike the rule. And in some cases very frank revelations about where they broke the rule and have now come to regret it. I like that format as most of the authors seemed to be very willing to discuss the frameworks mess ups and not just point to the parts they got right. It makes it seem much more human and approachable to me now.

There is not a lot of examples in the book though, it is mostly about building a style and set of guidelines for your application framework. I think this would make a great read for entry level programmers to help them understand the why you don't allow them to change the way things are exposed publicly, or to programmers who are looking to start designing APIs and are just looking for guidance. It is not a concrete how to build an API for doing "sometask". It is all about the theory behind API design and why you should employ the rules.

I have experienced many of the pains they explain in the book first hand (especially about Interfaces). Wish I would have read it before I released the first version of our API. I am implementing some changes based upon what I have read here, so it is definately a worthy book for those looking to take their design skills a little further.

If you are doing .NET development, you must have this book by your side. It is a great reference and it is very readable. It is great to just flip through and pick out a topic or to read from start to finish.

The knowledge the notes included by industry leaders provide great insight into the 'why' of the decision to do what they did. They also point out the mistakes made in the framework design that often lead to confusion when using the framework.

It stands as our coding standard on our team for framework development. It gives our team a solid base of information to refer to, especially when arguing about religious issues and doing code reviews.

The CD includes classes (videos) that teach every chapter of the book. It is like getting a complete college course for the price of a book.

If you don't have this on your shelf or in your backpack, do not bother interviewing for my team.

This is an excellent book for .NET developers, although I wouldn't recommend it for beginners. I read it a few years ago when I first started in .NET and found it a bit overwhelming. However, after reading it again with a few more years of .NET under my belt, I found the book very informative and helpful in terms of understanding not only how public APIs should be built, but also excellent tidbits about various .NET coding best practices that are applicable to developing just about any type of app.

One other thing I'll mention about this book is that it is geared toward developing a public API, so many of the recommendations may not be applicable to your specific situation. Indeed, for the development of most apps that aren't going to be used by other developers, much simpler coding approaches and architectures can and should be used. Despite that, however, this book has a lot going for it and you'll certainly gain a much deeper understanding of .NET after reading it.

I've bought this book three times: the first edition, the second edition, and the Kindle edition (for searching).

The authors don't just give you guidelines; they give you the reasons behind the guidelines. These reasons are ones learned at Microsoft during the development of the .NET Framework. They tell you what worked and what didn't.

You get multiple points of view, sometimes dissenting. There are, by my count, 25 reviewers / annotators, including Anders Hejlsberg.

The chapter on Common Design Patterns is one I reference frequently.

There are other gems in here, such as Appendix C: Sample API Specification:

"APIs that were designed by writing code samples before actually designing the API are generally successful. APIs that were designed before code samples were written to show how the resulting APIs should be used are often too complex, not self-explanatory, and ultimately need to be fixed in subsequent releases."

If your first instinct upon being told "do it this way" is to ask "why?", this is the book for you.

Brimful of divine wit and wisdom, this book actually was written by the creators of a universe. In a departure from biblical tradition, it is comprehensive, internally consistent and rarely ambiguous. It is also surprisingly entertaining and engaging.

Known inconsistencies and ambiguities are called out and explained, sometimes apologetically, as the gods of dotnet expound principles and then explain their own acts of creation to illustrate best practice - or sometimes worst practice, when they failed to heed their own advice. The text is littered with inset comments, as though the authors were standing around reviewing a draught of the book with you. They don't always share opinions, and the voice of dissent is as instructive as the explications.

I bought the first edition and loved it, giving it into the hands of someone who needed it. Now I have the second edition. Every now and then I skim it just to refresh my understanding, and sometimes to glean new insight in the context of more experience. Few of us will ever write an application framework, yet I think all of us would be better programmers if we shared the wisdom of those who do. Buy the book. If nothing else it's a hell of a conversation piece.

Not exactly what i was looking for, but a it's a great book, it explain the best practise to create a framework

I would only recommend this book if you're an intermediate or advanced .NET developer as there's a lot of high-level concepts discussed. Understanding the premises of object oriented programming is important as the book will talk about various techniques revolving this main concept. The book does feel very much like a textbook and can be dry but nonetheless, you'll pick up a thing or two that will make you a better programmer. I found the random comments throughout the book to be a good supplemental feature to the topic being discussed as some are key personalities in the industry; and it's always good what they have to say.

Lastly, the included DVD is just a presentation that can be found easily online, so it's nothing to be excited about. If you're looking to become a better API designer, or a better programmer, the book is a must-have. On the other hand, if you're a novice, you'd want to maybe hold off buying until you've understand the basics of OO and programming in general.