On deprecation
Original blog post title: Deleting code is one of my favorite things
This blog post is in response to a number of inquiries on the future of certain Enterprise Library features (this one, for example) and is meant to expose our thinking on code retirement/deprecation.
Let me start by saying that we don’t make deprecation decisions lightly and do our due diligence analyzing all the pros and cons. The most important factor for us is whether a feature continues to provide value considering the current state of Microsoft platform. In the past 3 releases of Enterprise Library, we’ve been extremely careful not to break the public API, even if we had to refactor the guts of the Enterprise Library. Given the ever-changing nature of software development, though, sometimes breaking changes are inevitable. In order to understand what drives our decisions, I think it’s worthwhile to reiterate the mission of Enterprise Library.
Microsoft Enterprise Library has always looked at the sweet spot between what the current version of the framework provides and what our customers seek in terms of additional assistance that they need to build and maintain their applications efficiently. I like the way my friend and colleague Eugenio Pace explains our, p&p’s, mission.
The horizontal axis represents time and the vertical one represents capability/features. With each new release of the platform you get more and more capability (see the blue trend). The platform gives you a lot, but clearly not everything; otherwise you wouldn’t need to write any code at all. The orange line represents the cumulative capability of your app. In order to help you with that, patterns & practices builds guidance in the form of reusable components and conceptual patterns. Using EntLib as an example, it provides you with a lot of plumbing like logging, validation, data access, etc. to spare you from writing them yourself so you can focus on what matters to you the most – your application. So, the gap between what the platform offers and what you need to do in your code can be reduced by EntLib. This is illustrated by the green curve. It also shows the idea that sometimes the framework grows to cover everything EntLib does, sometimes it doesn’t, and that we release more often than the framework does.
So, filling the gaps and helping you build successful applications on top of the current platform is one part of our mission. Another part of our mission is to provide feedback to the product groups so that they can factor this into future releases of the platform. Because of our close interaction with customers and our frequent and short releases, we act as an effective conduit for communicating important scenarios, patterns and trends to the product groups, de facto influencing future releases of the platform.
When the platform “catches up” with these scenarios, through new releases or through other add-ons or out-of-band features, there’s often little sense in carrying EntLib’s support for them forward and they can be naturally retired. This in turn gives us an opportunity to focus on the next wave of innovation. There are always many new areas for the Enterprise Library team to explore. The types, styles and design of applications, and the opportunities/problems that they are built to address, are forever changing. Our goal is to continually evolve EntLib so that it always provides great support to those building solutions on the current Microsoft platform.
Sometimes we delete code when we recognize that the feature we built is not used much, as was the case with the WMI support in EntLib 4.1. Carrying it forward required a substantial investment and wasn’t justified, and removing it in v5.0 simplified our code base significantly and proved to be a good decision. Sometimes we refactor code if it simplifies things. We’ve also removed design-time assemblies, several layers of indirection, and got rid of some other historical cruft. Between EntLib 4.1 and 5.0, around 200 classes were removed (though 120 significantly less complex classes were added) and the number of assemblies reduced from 89 to 33.
At other times, we deprecate code when it becomes clear that it may no longer be needed because of new platform technologies or features. If you are able to adopt these new technologies, then the corresponding application block or feature in EntLib would no longer be required.
For example, if you are architecting a new application and want to take advantage of object relational mapping (ORM) to model domain entities based on real business concepts rather than database structure or other reasons (debated here and here) then the Entity Framework may be a great choice. If you're doing brownfield development, though, it probably doesn't make sense to rewrite everything. There are many stored procedures still in use and in the enterprise world and there are still lots of complex, hand-tuned SQL. In this case, the Data Access Application Block may still be a good choice, even 6 years since its first release and with many new technologies available in the data access space.
Often, the choice is not as clear cut as one would hope. We always try to provide guidance on a transition path where available and keep the development community updated on our plans. For example, for those who have made the investment into using the Data Access Application Block, we try to extend these items to take advantage of some of the platform advancements where we can, such as the data accessors – a new approach to consume query results in a LINQ’able way introduced in the Data Access Application Block v5.0.
Another example is the Caching Application block. Since 2005, it’s been providing an easily configurable in-memory cache and persistent cache for desktop and server side apps. For Web apps, our recommendation was to use ASP.NET’s rich caching framework. If, however, you were developing an application that needed to run both as a Web app and a smart client, then the Caching Application Block provided a nice level of abstraction and allow you to use the same code on both the client and the Web server. These days, the Caching application block is being deprecated from the desktop version of Enterprise Library (we’ve already announced this). The reason is there are now new .NET Framework 4.0 System.Runtime.Caching classes and robust distributed caching support in the latest AppFabric (formerly known as Velocity).
On the other hand, there is no data caching support built in to Silverlight. So, based on our discussions with the product group, our advisory and community voting, we’re building that caching support in the Silverlight Integration Pack (it’s already available for preview if you are interested). To make the future transition smoother we are mimicking the interfaces from System.Runtime.Caching so all you will need to do is replace the corresponding references.
Similarly, with all the improvements in the security stack that have been added to the platform and the latest WIF developments, the Security Application Block no longer provides much additional value. Therefore, it is quite likely to be also deprecated in a future version of EntLib. We are currently assessing the deprecation path.
Another candidate for deprecation is the Cryptography Application Block. The Crypto API of the framework has come a long way from what it was when the Crypto Application Block has been introduced. The Crypto API is sufficient now for most scenarios and is quite easy to use. Besides, it provides support for asymmetric encryption, which the Crypto block never did.
To put things into perspective, Enterprise Library is 6 years old with some application blocks even older than that – a lifetime in the technology world! While it still provides lots of value in the areas of validation, logging, data access, exception handling, dependency injection (with Unity), and interception, there are other areas that are good candidates for careful deprecation.
Hopefully this post explains our approach to code deprecation in Entlib. If you are a user of any of the candidate blocks and have a strong case why they should stay in EntLib vNext, feel free to share that with me and the team.
In conclusion, Enterprise Library will always evolve to complement the current Microsoft platform. We will continue to work with the platform teams to ensure that our customers have a compelling development platform so that can quickly and easily build successful applications.
Acknowledgements: Thanks to my p&p teammates David Hill, Bob Brumfield, Chris Tavares and RoAnn Corbisier for reviewing the draft of this post.
Comments
- Anonymous
September 02, 2012
The comment has been removed - Anonymous
September 02, 2012
The current version of the Caching Application Block (5.0) works fine with both .NET 4.0 and 4.5. You can continue using it. The deprecation we announced 2 years ago means we are not investing into developing it any further since the platforms now offer these capabilities and there's no need for us to provide overlapping functionality.