What is an application framework?

Application Frameworks are collections of libraries (or code) prevalent in many large IT shops. Frameworks can be expensive to develop properly but the cost is more than offset by the advantages they provide. Some of these advantages include things like code quality, promoting code reuse, standardization of tasks and alleviate overhead that can be common across multiple applications.

Open Source Examples

You could spend days on Google and Bing researching the vast number of available options. We'll save you some time though...The two most prevelant examples in the .Net world are Spring.NET (http://www.springframework.net/) and CSLA.NET (http://www.lhotka.net/Default.aspx). Both of these examples are truly fantastic, robust, open-source frameworks that are geared towards large enterprises. So why build our own?

The Rationale for Building Our Own

Our experience with frameworks is mixed at best. The advantages frameworks provide certainly outweigh the cost but even with the examples given above, complexity quickly becomes an issue. Because these frameworks are geared toward large enterprises and attempt to be all things to all people they are inheritantly complex. Don't get me wrong though, complexity in and of itself is not necessarily evil. In the situation where you are implementing an enterpise framework for a large organization complexity is a fact of life. We find that in the case of most clients the complexity these frameworks introduces an element of risk that is not necessary.

After evaluating the available options and weighing the pros and cons we decided that instead of trying to fit the proverbial square peg into a round hole, we would use our experience and expertise to develop an application framework that is more suited to a small or medium-sized business.

The Enterprise Framework

We chose the name Enterprise Framework because although the framework is geared towards small and medium sized businesses the framework is robust enough to accommodate growth and has the ability to easily scale to support an enterprise application. In fact, the major difference between our framework and other commercially available frameworks is simply scope. The scope of our framework is limited to provide features and functions that are most commonly used in our client projects (such as Data Access, Security, Logging, Error Handling, Email, etc). By taking removing the requirement that our framework accommodate 'everyone' we were able to remove alot of complexity associated with application frameworks.

Our framework currently consists of the following modules:

• EnterpriseFramework - The base module that provides common functions such as Data Access, Security, Logging, Configuration, etc)
• EnterpriseFramework.BusinessObjects - Specific to each client and is generated from the client database (Code Generation - Object-relational Mapping)
• EnterpriseFramework.Services - Provides supports for Web Services (ASMX, WCF)
• EnterpriseFramework.Web - Provides basically functionality for web application such as Security, Caching, URL Rewriting, Visitor Tracking, Localization, Globalization, etc.
• EnterpriseFramework.Web.Controls - An advanced add-on for the web module that provides controls and utilities based on the Telerik Ajax Web controls
• EnterpriseFramework.Windows - A mirror of the web module but geared toward providing similiar services to a windows application.

One of the things we frequently see when a client-project uses masterpages is the following type-cast:

MasterPageType myMasterPage = Page.Master as MasterPageType;

To avoid this type-cast you can simply add the following directive to your page:

<%@ MasterType VirtualPath="~/Site.master" %>

Adding this directive to your page will make the Master property strongly-typed (Page.Master remains loosely-typed) to your masterpage eliminating the need to do the aforementioned type-cast.

While there are many different ways to implement web services the two predominate architectural styles are REST (REpresentational State Transfer) and SOAP (Simple Object Access Protocol). Each style has is own pro's and con's and it is necessary to objectively balance the appropriateness of each when selecting the implementation of your next service. So what's the difference at a high level between the two?

SOAP (WS-*) services are geared toward the enterprise and are inheritently more complex. For each SOAP service you define a contract using the Web Service Definition Language (WSDL). This contract specifies precisely the XML request and response messages needed to interact with the service. The SOAP (WS-*) standards address things like reliability, transactions and message-based security which are important when dealing with any value added transactions. Obviously there is a cost for this functionality in terms of overhead and complexity.

If a SOAP service is consider the 'yin', then the REST service would definitely be the 'yang'. Simple to implement with no contract to define a REST service can be broken down to four actions:

- GET - Gets the Resource
- POST - creates the Resource
- PUT - Updates the Resource
- DELETE - Deletes the Resource

This simplicity means quicker development time, lower overhead although you sacrifice features. For services that are dealing with non-critical data REST services are definitely the way to go.

So which will you choose? We say let the REST versus SOAP debate rage on.Luckily for you, you don't have to be caught in the middle. The Microsoft Windows Communications Foundation (WCF) framework provides you with the flexibility to easily change the method your service uses to communicate and even allows you to service both REST and SOAP requests with the same service.

Central Florida Software Group Blog Introduction.