ASP.NET AJAX Team Blogs

.NET Fireside Chats - Brad Abrams and Krzysztof Cwalina

The .NET Zone just published an interview with Kry and me. Check it out: .NET Fireside Chats - Brad Abrams and Krzysztof Cwalina You can learn some interesting stuff about what lead to writing the first edition of the book, what a 'Framework' is and what the hardest framework design problems are. I'd love to hear your feedback and thoughts Oh, and they published a sample section of the book for free in PDF format. This is from Chapter 9 and covers LINQ guidelines . Enjoy! Read More...

Framework Design Guidelines: Avoiding custom delegates

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2nd edition .. This content is found in the Events and Callbacks section of Chapter 6: Designing for Extensibility. I am impressed by how simple new additions to the BCL can have such a large (and positive) effect on framework design. As these new advances come out, learn them and use them! DO use the new Func<…>, Action<…>, or Expression<…> instead of custom delegates, when defining APIs with callbacks. Func<…> and Action<…> represent generic delegates. The following is how .NET Framework defines them: public delegate void Action() public delegate void Action<T1...

Framework Design Guidelines: Sealed Classes

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This content is found in the Extensibility Mechanisms section of Chapter 6: Designing for Extensibility. It is interesting to watch as new development methodologies become more popular and how the color the guidelines… CONSIDER using unsealed classes with no added virtual or protected members as a great way to provide inexpensive yet much appreciated extensibility to a framework. Developers often want to inherit from unsealed classes so as to add convenience members such as custom constructors, new methods, or method overloads. For example, System.Messaging.MessageQueue is unsealed and thus allows users...

Framework Design Guidelines: Extension Methods

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This content is found in the Extension Methods section of Chapter 5: Member Design. One of the major new features we added to the Framework recently is extension methods. While this a very powerful new feature, it does come with some new responsibility. CONSIDER using extension methods in any of the following scenarios: To provide helper functionality relevant to every implementation of an interface, if said functionality can be written in terms of the core interface. This is because concrete implementations cannot otherwise be assigned to interfaces. For example, the LINQ to Objects operators are implemented...

Framework Design Guidelines: An appeal for consistency

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This content is found in the Names of Classes, Structs, and Interfaces section of Chapter 3: Naming Guidelines. Even in the .NET Framework we don’t always apply the design guidelines consistently – and, as Phil found out, we often pay the price for it. DO ensure that the names differ only by the “I” prefix on the interface name when you are defining a class–interface pair where the class is a standard implementation of the interface. The following example illustrates this guideline for the interface IComponent and its standard implementation, the class Component: public interface...

Framework Design Guidelines: Naming New Versions of Existing APIs

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This content is found in the Naming New Versions of Existing APIs of Chapter 3: Naming Guidelines. Incrementally evolving an existing, popular API is very hard. My main take away personally from this guidelines (and Kit’s annotation) is to work hard to get it right the first time! DO use the “64” suffix when introducing versions of APIs that operate on a 64-bit integer (a long integer) instead of a 32-bit integer. You only need to take this approach when the existing 32-bit API exists; don’t do it for brand new APIs with only a 64-bit version. For example, various APIs on System.Diagnostics...

Framework Design Guidelines: Avoiding Abstractions

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This content is found in the Principle of Self-Documenting Object Models section of Chapter 2: Framework Design Fundamentals. I love the war-stories that our annotators provide here. AVOID many abstractions in mainline scenario APIs. KRZYSZTOF CWALINA Abstractions are almost always necessary, but too many abstractions indicate over-engineered systems. Framework designers should be careful to design for customers, not for their own intellectual pleasure. JEFF PROSISE A design with too many abstractions can impact performance, too. I once worked with a customer who re-engineered its product to incorporate a heavily...

Framework Design Guidelines: Supporting Experimentation

Continuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This content is found in the Framework Design Principles section of Chapter 2: Framework Design Fundamentals. I love the history and real world color Chris brings to this guideline with his annotation. Some APIs lend themselves to experimentation and some do not. To be easy to experiment with, an API must do the following: Allow easy identification of the right set of types and members for common programming tasks. A namespace intended to hold common scenario APIs that contains 500 types, out of which only a handful are actually important in common scenarios, is not easy to experiment with. The same applies...

Framework Design Guidelines: Scenario Driven Framework Design

Ccontinuing in our weekly blog post series that highlights a few of the new additions to the Framework Design Guidelines 2 nd edition .. This annotation is found in Chapter 2: Framework Design Fundamentals. Joe and Chris nail the core things. JOE DUFFY As software developers, we enjoy creating fun and powerful new capabilities, and sharing them with other developers. That’s one of the reasons API design is so enjoyable. But it’s also incredibly difficult to step back and objectively assess whether some new capability that you’re particularly passionate about has utility in the real world. Using scenarios is the best way I know of to identify the need for and ideal usage of new capabilities. Developing scenarios is in fact incredibly...

NextGenUG PodCast

It was my good luck to run into Dave McMahon and Richard Costall from NxtGenUG today at the MVP Summit here at Microsoft… We had such a great time chatting they wanted to do a quick little interview for their podcast… Show #30 - The One With The Maracas ... [ list ] You can catch me at about 25:40 We start off talking about the Framework Design Guidelines book and how it is “required reading” at many companies… I am pleased to hear it and I am very happy that the book can be saving so much time for folks so they can void the arguments and just get to work… We also talked a little about WPFE, Longhorn Server, ASP.NET futures, the Design world and, of course, Mix and more! Love to hear what you think! Read More...