I gave a talk on the Microsoft Application Blocks for .NET last night at the Capital Area .NET Users Group, which I help run as an executive member. Our scheduled speaker cancelled on us with short notice, so I had to jump in and pinch speak. Luckily I have given this talk a couple times before, at the WeProgram.NET and NW Ohio .NET Users Group, so it wasn’t much of a stretch to give it again with only a few hours notice.
The talk seemed pretty well received. Lots of analogies drawn by some members of the crowd familiar with Java between the UIP and Apache Struts.
If you are not familiar with them, the Application Blocks are a set of best practice implementations that save you from writing common infrastructure code in your apps for a variety of situations. The current list of blocks include:
Data Access Application Block
Provides a thin, easy to use API on top of ADO.NET that can result in considerable code savings and cleaner code for data access.
Exception Management Application Block
Allows you to publish exception information to a variety of publishers with a single line of code in your catch blocks that does not need to change to publish the information to different locations – it is driven by publishers that are plugged in and wired up through the config file.
Configuration Management Application Block
Allows read and write access to configuration data in config files, other XML files, SQL Server, or the registry, unencrypted or encrypted, all with what comes “in the box“ with the block. You can also plug in custom storage and data protection providers.
User Interface Process Application Block
A model-view-controller pattern implementation for Web or Windows Forms applications that allows you to fully decouple the individual views of your application, even if those views form the steps of a navigation flow in your application. The controller manages the navigation flow between views using information in the config file and also manages the shared state between views. As a result, views never have to explicitly navigate to another view or pass it state, the controller and underlying classes in the block manage all that for you.
Application Updater Block
Allows you tomake your apps auto-updating in a distributed or web-based environment. The blockmakes it easy for your apps to goout and check a known location to see ifupdates to your application have been deployed, and if so, downloads them and applies them on next run.
Supports the need in distributed, service oriented applications, to only retrieve data from services when needed by caching retrieved results at the call site. Supports a variety of caching scenarios and persistence providers. Works in conjunction with the Aggregation and Asynchronous blocks if desired, or can be used standalone.
Supports the need in distributed, service oriented applications, to retrieve data from multiple sources and have it presented to your application as a single set of aggregated data. Works in conjunction with the Cachingand Asynchronous blocks if desired, or can be used standalone.
Supports the need in distributed, service oriented applications, to retrieve data in an asynchronous fashion so your app can continue doing other things until the data becomes available, which it finds out about through callbacks from the framework. Works in conjunction with the Cachingand Asynchronous blocks if desired, or can be used standalone.
These are the ones I am most familiar with. There is also a Logger block that came out recently that builds on the Enterprise Instrumentation Framework, but I haven’t played with that one yet. You can find these through various searches on MSDN or GotDotNet workspaces.
Best centralized link is Ron Jacob’s page on GotDotNet – lists alll the block lins: