Overview

Recently, I noted the progress on the new Announcements Provider that we're sharing with the DotNetNuke + metaPost community. For those who are interested, here's a few notes regarding the architecture that we've used.

Creating the Announcements Provider was a bit of a challenge due to the fact that this (and every) provider is essentially built "on top of" an existing 3rd party module (albeit, one of the core DotNetNuke modules). The challenge lies in the fact that we have no control over the architecture or code of that 3rd party module. Often, module developers think of their module as extending DotNetNuke, and while they (rightfully) expect stability in the DNN¹ API, they often don't think of their own modules as being something that others might want to extend. As such, it's not uncommon for a team of module developers to make code changes in new versions that effectively "break" other people's extensions of that module. Such was the case for the Announcements module.

The metaPost Announcements Provider (which I'll simply refer to as the mAP² for the rest of this article) was built to support older versions of the Announcements Modules. Basically, the idea was to target modules that were around the release of DNN 04.05.x, which was the first DNN version targeted by metaPost. Since then, the versions of Announcements that are going to be targeted for mAP are 03.03.05 and upward. But, there were some significant changes in method signatures between version 03.04.00 and 04.00.00. Realizing that these changes meant not only some code bloat for mAP, but also that future "breaking" changes might occur in Announcements, it became apparent that some kind of architecture to deal with these changes was needed for our provider.

Basically, the architecture selected for mAP was to separate out the code that would a) map data from people's posts to the data stored in Announcements and b) deal with the version changes of the Announcements module. To do that, we used an adapter⁴ to do the data mapping and a factory⁴ to deal with version changes.

The Adapter

The adapter is the simplest part of the architecture. Basically, it consists of a single class with two static methods:

• FillAnnouncementInfo - for mapping data from metaPost to the AnnouncementInfo data, and
• ExtractAnnouncementInfo - for mapping data from AnnouncementInfo objects to metaPost

FillAnnouncementInfo basically allows creating or updating announcements while ExtractAnnouncementInfo is used for getting (opening) previous announcements in WLW or MS Word³. Here's a screen shot of the class diagram.

The Factory

For designing the "Factory", I simply used the Factory Pattern⁴ to deal with changes to the controller classes of the Announcements module. This meant the creation of four classes:

• ControllerFactory - the class that is responsible for creating (and encapsulating) the "proxy" controller classes.
• AnnouncementsController_Proxy - this is an abstract class that inherits from the AnnouncementsController and that defines the "replacement" methods to use for those that were changed in later releases of the Announcements module. The methods we needed to "replace" were the ones that added and deleted posts.
• AnnouncementsController_3_3_5 - this is a concrete class that supports the method signatures for versions 03.03.05 and 03.04.00 of the Announcements module.
• AnnouncementsController_4_4_0 - this is the concrete class that supports the Announcements module's new method signatures for version 04.00.00 and higher (or at least, until the next breaking change).

Here's a screen shot of the class diagram. Note that the abstract and concrete classes are actually internal to the ControllerFactory class. This is by design, largely to encapsulate (hide) the creation of the classes and to "force" us to only use the ControllerFactory.CreateController() method.

Summary

What all of this allows us to do is to a) remove the complexities of breaking changes from the AnnouncementsProvider class, and b) position ourselves to deal with any possible breaking changes when future Announcements Module versions are released. In later posts, I'll release explanations of how the architecture and code works to achieve these goals.