Application Frameworks
Recently, I've been seeing the value of application frameworks, like the Membership and Roles frameworks. Having the capabilities for your application, custom controls, and other objects to work together through a common API, components working together provide some business value. For instance, in an example of mine, I created a custom Page class (named PageBase), which exposed a Security property. This property was a complex object that had various security-based components I used in my application.
In my custom control library, I had an AdministratorPanel class, which in my application pages that use this PageBase class, whenever I use this AdministratorPanel in one of those web pages, I can access the Page property, converting it to a PageBase, and if the page class is actually my custom page, then I can make use of this security feature. The following is the code:
if ((this.EnableViewState && !Page.IsPostBack) || !this.EnableViewState)
{
PageBase page = this.Page as PageBase;
if (page != null)
{
//Only make it visible if the user is an administrator
this.Visible = page.Security.IsInRole("Administrators");
ViewState[VISIBLE_VIEWSTATE] = true;
}
}
It is important to use error handling to ensure if the developer is using your application framework. For your own internal applications, it is fine; however, if you are developing something for public use, maybe the developer only wants to use several of your components in the framework. That is one of the drawbacks with application frameworks, is that they can be severely coupled. Coupling is the concept that states how well objects can work without referencing each other. So an application framework would be a coupled application, whereas the enterprise library, which its components can be used without referencing other components, is decoupled.
Comments
