Freigeben über

Framework Design Guidelines 2nd Edition

  • Artikel

My blog was relatively silent for several weeks. First, I was traveling to Europe for the TechEd, then was busy at work, then the holiday break. It's time to go back to more regular posting.

I will start with an announcement (or at least a more formal and broader announcement): after my TechEd presentation, the first question I got from the audience was whether we are working on a new edition of the Framework Design Guidelines. The answer is "yes", which I am super excited about. Right before the conference, we signed formal documents with the publisher and started wortking on the book. It's going to cover the new features in the .NET Framework 3.0, 3.5, and new advances in languages (e.g. LINQ) that are relevant to Framework design. BTW, I would appreciate feedback on what specifically you would like to get covered or clarified.

We are shooting to have the book ready around the end of 2008, but the publisher already sent me a draft of the cover art:

Comments

  • Anonymous
    January 03, 2008
    The comment has been removed

  • Anonymous
    January 03, 2008
    This is really good news. I am really looking forward to reading it.

  • Anonymous
    January 03, 2008
    Excellent news!

  • Anonymous
    January 03, 2008
    The comment has been removed

  • Anonymous
    January 03, 2008
    Krzysztof spilled the beans ... We just started working on Volume 2 of the Framework Design Guidelines...

  • Anonymous
    January 03, 2008
    Krzysztof spilled the beans ... We just started working on Volume 2 of the Framework Design Guidelines

  • Anonymous
    January 03, 2008
    This is just awesome news. Now, where do we apply for early review copies? ;-) No. Seriously :-)

  • Anonymous
    January 03, 2008
    This is fantastic news!  I can't wait.  Like Tom K-G, I too volunteer for review duties.  I gave you a decent amount of feedback on the 1st ed, but that was after publication. Some specific points:-

  1. I don't think the title "Framework Design Guidelines" does the book justice.  Your guidelines are not just for reusable .NET libraries.  The book should be read by every .NET developer, not just framework designers.  I think of FDG as "Effective .NET".  Is it too late to change the title to reflect/promote its wider appeal?
  2. It would be nice to have some guidance on multi-threading, including: lock attempts that timeout, the volatile keyword, CPU cache lines, the SynchronizationContext class, the CallContext class, and more.
  3. Memory: include guidance on weak references, SafeHandles over finalizers, etc.
  4. Cross-language gotchas, such as VB's exception filtering code being invoked before the exception-throwing C# code's finally block has run.
  5. Transactions.  Include guidance on the goodness that's available in System.Transactions.
  6. And of course I look forward to as much C# 3.0 guidance as you can give. Andrew

  • Anonymous
    January 03, 2008
    I have the first one, I won't get a second version, but I would consider it if the chapters that deal exclusively with new stuff in .NET 3.0 and 3.5 would be released separately.

  • Anonymous
    January 03, 2008
    Great news, I'm really looking forward to the new edition.

  • Anonymous
    January 03, 2008
    I don't want to start a naming convention war, but you should define conventions for private members. Developers often work on several teams and use tools to validate naming conventions. Having to reconfigure your tools and your mind when you change projects is a pain. BTW, I hate prefixing a member just because it's private.

  • Anonymous
    January 04, 2008
    How about some discussion about how tio deal with covariant collections?  I.e., something like DoSometingWithItems<T>(IEnumerable<T> stuff) where T : SomeBaseClass I've seen way too many people assume that they need to specify IEnumerable<SomeBaseClass> as the parameter and run into all sorts of issues with getting collections of derived types to work.  It looks obvious but it's something that people easily mess up.

  • Anonymous
    January 04, 2008
    Also, advice about implementing IEquatable<T> within an inheritance hierarchy would be nice. For example, I have IMyInterface, MyClass : IMyInterface and MyDerivedClass : MyClass. I want to implement IEquatable on the interface but I want to ensure that EqualityComparer<T>.Default uses the methods even if someone uses MyClass or MyDerivedClass as the type params.   Advice on how to implement the interface at each level and dealing with the various Equals overrides would be very helpful.

  • Anonymous
    January 04, 2008
    Hi Krzysztof, great news. Not sure if this is appropriate for the book, but I'd really like to find some 'canonical' documentation on use scenarios for LINQ, the ASP.NET Dynamic Data Controls and when to use SQL Metal directly.  Additionally, I'd like to find out the limitations of these code gen approaches and when its best to continue to write code by hand (what are the upper limits of their customizability?).  Also, performance patterns for LINQ -- how often should we create instances of data Context objects, can you cache them, creat singletons (gasp), etc

  • Anonymous
    January 04, 2008
    From the first edition, I loved the comments made by PM's/Devs on the framework, what they should have done, what could be done better, etc. Make sure that type of thing gets into the new stuff! <g>

  • Anonymous
    January 04, 2008
    I vote for WPF guidelines. With WPF there are 10x as many ways to solve problems than plain .NET. This means there are 10x as many ways to shoot yourself in the foot. How about 10x as many guidelines for the WPF side of things? :)

  • Anonymous
    January 05, 2008
    Some best practices on designing libraries that have extension methods would be good.

  • Anonymous
    January 05, 2008
    Hi! It would be great to see a chapter for Model-View-ViewModel WPF pattern. Kazi

  • Anonymous
    January 08, 2008
    Thanks for all the support, comments, and suggestions. Some of the things are already on the list, some are great new suggestions. The topics we want to avoid are all that are not related to API surface area design. We want to keep the book focused and be the definitive source of information on API design; we will never succeed at being the definitive source for information about everything related to .net development. Having said that I am dreaming about writing something like Framework Architectural Guidelines (layering, dependencies, threading, etc.), so maybe one day all of these suggestions will find their way into a Framework guidance book.  Mike, I have already made some updates to the manuscript inline (comments and errata items from readers) and clarifications to some existing guidelines, but majority of the new content will be easily identifiable and separated. I don’t think we will have many new chapters, but definitely many new sections in existing chapters and based on your feedback I will add a list of added sections to the front matter. Thanks for the feedback. Paulo, naming conventions for private/internal identifiers is something that many people ask. There is an appendix in the book that talks about these. Having said that, I prefer for these to keep being informal as I also don’t want to get into internal team naming wars :-) Public identifiers are a different ball game; they affect productivity of people outside of the internal dev team (and that’s the main focus of the book).

  • Anonymous
    January 08, 2008
    Oh, for those who would like to review the manuscripts, please send me email (kcwalina at microsoft.com) expressing interest and with a premission to forward it to the publisher. And Thanks! Feedback from people passionate about API design is invaluable!!!

  • Anonymous
    January 08, 2008
    Also, I just updated the picture of the cover to reflect Anders's change in the title.

  • Anonymous
    January 08, 2008
    Here's another one (that I'm sure will tick off some folks): less special sections on Visual Basic. Seems like MS always gives VB special attention, even in terms of it being a more "complete" .Net implementor than C#, but in terms of API design, there's a disproportionally large amount of annotations related to VB in what should be, by and large, a language neutral platform.

  • Anonymous
    January 15, 2008
    Krzysztof and Brad have announced they are working on the second edition of the awesome Framework Design

  • Anonymous
    January 17, 2008
    Krzysztof and Brad have announced they are working on the second edition of the awesome Framework Design

  • Anonymous
    January 18, 2008
    Krzysztof spilled the beans ... We just started working on the 2nd edition&amp;;of the Framework Design

  • Anonymous
    January 24, 2008
    Guidance  for data access to determine when to use LINQ, ADO.NET, Entity Framework, typed DataSets, etc in different scenarios would be useful. Given all of the data access options, even alternet options like SubSonic and nHibernate, it is getting harder to maintain legacy applications that choose all kinds of unexpected approaches. It appears that LINQ data contexts will replace typed DataSets, but a prescribed approach given all of the available options would be very useful over the next several years.

  • Anonymous
    February 14, 2008
    The new Async-Pattern (Event-based Asynchronous Pattern) in the .NET Framework 2.0 used for classes System.Net.WebClient, System.Net.NetworkInformation.Ping, System.ComponentModel.BackgroundWorker etc. (Not BeginnXXX and EndXXX but that XXXAsync, XXXAsyncCancel) There are many naming conventions for classes, events and methods in this Pattern.

  • Anonymous
    March 13, 2008
    You know that I&#39;m a big fan of framework and library design so also have been a big fan of Framework

  • Anonymous
    March 16, 2008
    First I would like to thank you (and Brad Adams) for writing this very essential book. About the 2nd edition, I would really like to see more guidelines on how to organize your types in a namespace hierarchy and on how to package these same types into different assemblies. Even though the two concepts really are quite unrelated and orthogonal, they often get mistakingly intermingled. So it would be really helpful to have guidelines to help you to think straight when performing these tasks.

  • Anonymous
    April 11, 2008
    I hope you keep the book focused on core parts of the framework and stay away from areas such as WPF, Card Space, silverlight.

  • Anonymous
    July 16, 2008
    These guidelines were just added as part of an update to the Framework Design Guidelines book ( upcomming

  • Anonymous
    August 16, 2008
    Krys and I just finished writing the update to the framework design guidelines and you are can already

  • Anonymous
    August 20, 2008
    I just bought early verison at the Rough Cuts http://safari.informit.com/9780321545671 Looks like a greta outline.  Stick with it.

  • Anonymous
    February 05, 2009
    [ Nacsa Sándor , 2009. január 19. – február 5.] Ez a Team System változat fejlett eszközrendszert kínál

  • Anonymous
    April 16, 2009
    Add a chapter or section devoted to service or WCF-related API guidelines.