Microsoft & .NET.NETCreating an Application Development Framework Using Enterprise Templates - Part 1

Creating an Application Development Framework Using Enterprise Templates – Part 1 content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Distributed Applications are often large, complex systems with multi-tiered architectures, comprising thousands of globally deployed components. These applications are expected to deliver a wide variety of solutions to address different kinds of customer and business needs. Before .NET, Windows DNA was the platform of choice for developing scalable and extensible applications in the Windows platform. With the arrival of .NET, things have not changed much in terms of the application design and reusable application framework.

One of the real strengths of .NET is its ability to allow application architects to enforce application architecture and provide architectural guidance using enterprise templates. By using Enterprise Templates, you can provide development teams with a starting point that is a lot more sophisticated than an empty solution, while reducing the number of decisions and complexity of choices that the developers must make. Moreover since most of the distributed applications are very similar in nature (in terms of application architecture, operational management and so on), a custom distributed application template of this kind will be very useful and can be used as the starting point while building new applications.

In this series of articles, I will present details on how to customize enterprise templates to create an application development framework that is based on the pre-defined application architecture. Along the way, you will also gain an understanding of how application architects can enforce policies by using the extensible new language named Template Description Language (TDL) thereby making the life of the developers that much easier. At the end of this series of articles, you will have built a complete application development toolkit (based on the application building blocks such as exception management, data access application block, configuration files handling, encryption and decryption and so on) that can be used by any development team to build a distributed web application.


When applications were developed using Windows DNA methodology, a pre-defined application development framework was used to start the development. Every time we develop a new application, we have to start from scratch, create our application framework to it and then go about developing the application.

To avoid the repetitive work, Microsoft created a set of pre-defined templates known as Enterprise templates that provide the base framework for developing N-Tier enterprise applications using the .NET Framework and Visual Studio.NET. These templates can be used as the basis for developing more complex applications. When developing applications, you can either use one of the existing templates supplied by Microsoft or customize one of the existing templates to create your template. If you are an application architect, you will find this feature immensely useful as it allows you to clearly communicate the application architecture to your developers. Moreover you can also provide your development team with an application development framework that is made up of application building blocks.

What is an enterprise template?

Before looking at enterprise templates, let us understand the need for enterprise templates. To answer this issue, we need to consider the common problems that developers, face during application development.

  • IT development projects are getting more complex, larger, and more critical
  • A poor application architecture can make any platform perform poorly
  • A good architecture only works if people follow the rules when implementing it
  • Good help is hard to find (and expensive!)
  • Developers have been faced with ever-increasing complexity as technologies and opportunities have proliferated.

The enterprise templates are designed to address all of the above problems. The Enterprise Template is an intuitive, productive, and cost-effective mechanism for rapidly developing Distributed Applications using Visual Studio .NET. Enterprise templates and the Template Description Language will help to reduce developer complexity and will increase collaboration across the development team.

The Enterprise Templates allow us to:

  • Rapidly define and communicate the initial structure of our distributed application
  • Provide architectural best practices and suggestions
  • Provide technological best practices and suggestions
  • Minimize collections of white papers, standards, and policies documents
  • Reduce complexity for developers by providing a clearly defined application development framework

Enterprise templates also enable companies to leverage their most experienced people to define development guidance and policy that can be easily used by developers for building applications. Instead of being limited to documents, this guidance can take the form of architectural blueprints, reusable components and policies or instructions for building applications — all delivered within the Visual Studio .NET environment.

Enterprise Templates also provide a powerful way to solve both the “blank slate” (no starting point) and the “full slate” (too many alternatives) problems. This innovative set of features enables organizations to provide architectural guidance within the Visual Studio .NET environment.

Structure of Enterprise Templates

The templates in Visual Studio .NET contain an initial project structure component, which is essentially the starting point for a software architect to begin building an application. The component can include reusable software components, classes and other pieces of technology. Templates also contain the policy associated with the project, in which an architect can outline which technologies a developer should use when creating the applications.

In VS.NET, Enterprise Templates consist of three major components:

  • An application template, which defines the initial project structure (base files, BCL assemblies that are included, etc.). You can draw analogies between the application template and the Active Template Library (ATL) from VS6. When you create a project in ATL the environment gives you some basic boilerplate files (the IDL, co-class files, .h files, etc.). Similarly, you can define what boilerplate files a user gets when they create a new project based on your template.

  • A policy file, which allows you to customize the VS.NET environment to a significant degree. The policy file is defined in TDL, which is used to specify the technologies that are appropriate at various points in a project. TDL also provides fine-grained control of property settings. For example, you can institute a policy that disables the managed C++ compiler and refuses to import certain BCL libraries such as System.Remoting. You can also configure certain compiler options (e.g., disallow unsafe code) using policy files. TDL also enables an architect to control the Visual Studio .NET environment, including the task list, toolbox, property browser, solution explorer, designers and editors, and even dynamic help. When a developer uses the template project, its associated policy is automatically applied within the context of the Visual Studio .NET environment. Policy can even be attached to pre-existing projects, with any violations referenced in the task list for easy correction.

  • Custom help topics — Using custom help topic files, you can provide guidance to the application development teams right within Visual Studio .NET IDE.

It is also possible to customize the enterprise templates to have a common application development framework. The frameworks are reusable components can greatly simplify programming tasks by including pre-written code to handle procedures such as application management, exception handling and so on. Together, the templates and frameworks enable companies to define and build applications based on best practices. In this article, we will create an application development framework that is based on enterprise templates and a set of reusable components.

A Quick look at Template Description Language (TDL)

An Enterprise Template is built using an XML grammar that specifies the projects, items, and constraints that comprise the template definition. The grammar elements in this table comprise the Template Definition Language (TDL) and represent the available grammar elements for constructing Enterprise Templates.

Enterprise Template Framework

In this article, we will customize the enterprise templates to come up with our own enterprise application template that can be used as the starting point for building web-based E-Commerce applications. While defining the template, we will also standardize on the common base application architecture that we want to establish in all of our applications. Along the way, we will also define the application building blocks (that provide services such as Exception Management, security, data access and so on) and implement them as part of the template.

Before we start customizing the enterprise template, let us take a quick look at the application components of a typical .NET enterprise solution.

As you can see from the above diagram, a typical .NET enterprise application is partitioned into logical layers based on their functionality. For example, all the business logic for the entire application is contained in the business logic layer, allowing us to encapsulate the business logic in the form of reusable components. Let us briefly define the different components of the above architecture.

  • User Interfaces:
    This layer is responsible for rendering the appropriate user interface for our application. Since our template is focused on web-based applications, normally these layers will be composed of one or many ASP.NET web applications.
  • Web Services layer:
    This layer consists of web service methods that allow us to expose the functionality to external consumers using XML over HTTP and SOAP.
  • Business Fagade layer:
    This layer consists of components that allow us to provide a consistent interface into the business logic layer. This layer depends on the business logic layer for all of its functionalities. This is normally created by Visual C# class library projects.
  • Business Services layer:
    This layer again consists of Visual C# Class library components that contain the core business logic for our application.

  • Data Services layer:
    This layer consists of ADO.NET Code to invoke the stored procedures or execute SQL statements in SQL Server 2000. The data services layer will leverage the data access application block from Microsoft for executing queries and stored procedures against the Sql Server database. We will add the data access application building block as part of the framework in the later stages of this article.
  • System Framework projects:
    These set of components provide the core services for our application and will be shared by all the layers of the application.
  • SQL Server database:
    The SQL server database contains all the stored procedures.

Now that we have seen the different components of our application architecture, let us take a look at the building blocks that we want to include as part of the template. Once defined, these building blocks will be part of every new application that is created by choosing CustomDistributedAppTemplate as the template.

Implementation of System Framework

In this section, we will create the system framework components that are shared by all the layers of the application. As we already mentioned, we will cover the following 4 components.

  • Data Access Application block
  • Exception Management Application block
  • Custom Configuration file section handling classes
  • Classes that provide encryption and decryption functionalities

Let us look at the creation of data access application block.

Data Access Application Block

When you are developing the data access layer for your application, most of the times, you will be writing the same data access plumbing code again and again. It would be very efficient to wrap the common data access code in the form of helper functions that allow you to call the stored procedure in a single line. With .NET, Microsoft themselves have created an application block named Data Access Application block that contains the optimized data access plumbing code that will help you call stored procedures and execute SQL statements against a SQL Server database.

We will use it as one of the building blocks as part of our distributed enterprise application template. This will go a long way in reducing the amount of custom code that we need to write, test and maintain. The data access application block also encapsulates performance and resource management best practices for accessing SQL Server database. Using the data access block, we can perform the following operations.

  • Invoke stored procedures or execute SQL commands
  • Specify parameter details
  • Return SqlDataReader, DataSet, or XmlReader objects

The data access block contains a class named SqlHelper that provides a set of static helper methods that can be used to execute a variety of different command types against a Sql Server database. It also contains a class named SqlHelpParameterCache that provides command parameter caching functionality that can be very useful in improving the performance of the application. The SqlHelper class provides five shared methods named ExecuteNonQuery, ExecuteDataset, ExecuteReader, ExecuteScalar, and ExecuteXmlReader. Each of the above methods provides a consistent set of overloads. This provides a well-defined pattern for executing a command by using the SqlHelper class.

For example, we can execute a stored procedure named GetCategories that takes a categoryID as an argument using the following lines of code.

DataSet ds = SqlHelper.ExecuteDataset( connectionString,           CommandType.StoredProcedure,           " GetCategories",           new SqlParameter("@iInformationTypeID", categoryID));

As you can see from the above, the ExecuteDataset method executes the stored procedure and returns a dataset as a result. For more information on data access application block, please consult the following link from Microsoft. Microsoft Application Blocks for .NET

For our application, we will download the data access application block from the above-mentioned link and add it to our enterprise template that we are going to be creating. Once the project is added to the template, it can easily be referenced from other projects in the solution using the Project References option. Once the reference is added, we can start using the SqlHelper class (that is part of the data access application block) methods to execute stored procedures and issue SQL commands. For the purposes of this article, we will create a custom data access project named SqlDataAccess that consists of the following classes.

  • SqlHelper class (that is part of the data access application block)
  • DBNullHelper class that provides helper functions for handling null values

You can download the code for the SqlDataAccess project along with the support material for this article.

Exception Management Application Block

In an ideal world, all the code you write would always run without error. But the reality is no matter, how carefully you write your code, errors can and will occur. For that reason, it is good to have an efficient error handling routine in place that can handle the errors in a graceful manner. It is also important to realize that the effectiveness of any exception handling solution is only gauged from the way it impacts the users experience when working with the application. Having seen the amount of time and effort spent by the developers in creating exception management systems, Microsoft created a powerful and extensible exception management application block that can be reused in any .NET application.

By using the exception management block, with a single line of application code you can easily log exception information to the event Log or extend it by creating your own components that log exception details to other data sources. As mentioned before, the Exception Management Application block can easily be used as a building block in any .NET application. The exception management block provides the following benefits.

  • Allows us to manage exceptions in our applications in an efficient and consistent way
  • Makes it possible to clearly isolate exception handling code from the application logic
  • Allows for handling and logging of exceptions with a minimal amount of custom code

To use exception management in our application, we need to perform the following steps.

  • Download the exception management application block from the following link.
  • Add the exception management and exception management interfaces projects to our solution.
  • Add reference to the exception management using Project References option.
  • Add using statement to reference the exception management block from your custom class.
  • Now you can publish exceptions by calling the Publish method of the ExceptionManager class as shown in the following line of code.
catch ( Exception ex ){   ExceptionManager.Publish( ex );}

Most of the times, you will be satisfied with the functionality of the default publisher, which writes exception details to the event log. However there are times, where you may want to extend the exception management block by writing your own custom publishers, which may log exception information to alternate locations. To accomplish this, you need to create a custom class that implements either the IExceptionPublisher or the IExceptionXmlPublisher interface defined within the Microsoft.ApplicationBlocks.ExceptionManagement.Interfaces.dll assembly.

For more information on the exception management block, please consult the Exception Management in .NET Architecture Guide.

Custom Configuration section handling classes

Before the arrival of .NET, we used to store global configuration settings such as connection strings in a centralized location like registry. But in the .NET world, all these global settings are stored in the application configuration file that is normally deployed along with the application code. For an ASP.NET web application, it will be web.config file and for a WinUI application, it will be app.config.

For example, the following appSettings entry in the web.config file can be used to store the connection string.

<configuration>  <appSettings>    <add key="connectionstring"    value="server=localhost;database=Northewind;uid=sa;pwd=;"/>  </appSettings></configuration>

We can read the above connection string from our code by using the following statement.

string connString = new ConfigurationSettings.AppSettings["connectionString"];

This simple key/value mechanism (stored in the appSettings section) is perfect for many common needs, such as storing database connection strings at application scope; but it’s not flexible enough for more complex data. As you can see, the data that is stored in the appSetttings section is in plain text, which renders it unfit for storing settings such as connection strings to the database and so on.

Fortunately, Microsoft also built in a mechanism for creating custom configuration classes that can be used to represent data in the configuration files. Rather than reading a hard-coded list of tags recognized only via code within a specific application, the .NET framework can also read one or more configSections (that define the tag names) and then use that information to identify blocks of information in the remainder of the configuration file. Before we look at the example application that implements the custom configuration section handling classes, let us understand the theory behind custom configuration sections. Custom configuration sections are placed into two main areas in the configuration file.

  • A configuration section declaration area- This is identified by the configSections element. For example, to create a configuration section named appConfigSection, we need to place the following settings within the web.config file.
<configuration>   <configSections><section    name="appConfigSection"    type="DistributedApp.AppFramework.ConfigurationHandler.ApplConfigSectionHandler,ConfigurationHandler"></section>  </configSections>   ..  ..</configuration>

As you can see from the above, we use the type attribute to specify the section handler class (that implements the IConfigurationSectionHandler interface) that will be automatically invoked, when the application tries to read the configuration information using the System.Configuration.ConfigurationSettings.GetConfig method. We will see the implementation of the ApplConfigSectionHandler class in a moment.

  • Configuration section settings area — This is the area where the actual configuration settings are stored. For example, in the following declaration we define the section settings under the appConfigSection element.
<?xml version="1.0" encoding="utf-8" ?><configuration>  ..  ..     <appConfigSection>    <appSection name="loggingSection" encrypted="true"><appSetting key="loggingEnabled" value="true"></appSetting>          </appSection>    </appConfigSection></configuration>

As shown above, we also have an attribute named encrypted in the appSection element that allows us to indicate to the configuration helper methods if the settings are encrypted. If the encrypted attribute is set to true, then the configuration helper method will decrypt the values before returning it to the caller. The encryption and decryption capabilities are available in the class library named Encryption, which is explained in the following section.

The code for the class that implements the custom configuration handler is as follows:

public class ApplConfigSectionHandler : IConfigurationSectionHandler{  public ApplConfigSectionHandler()  {  }  public Object Create(Object parent, Object input, XmlNode node)  {    XmlNodeList appSectionNodes;    XmlNodeList appSettings;    NameValueCollection arrAppSetting;    ArrayList arrSettings = new ArrayList();    string name;    string sname;    string svalue;    string encrypted = "false";      appSectionNodes = node.SelectNodes("appSection");//Loop through all the AppSection nodes and add them to the ArrayList    foreach(XmlNode appSectionNode in appSectionNodes)    {      arrAppSetting = new NameValueCollection();name = appSectionNode.Attributes.GetNamedItem("name").Value;XmlNode encryptedAttr = appSectionNode.Attributes.GetNamedItem("encrypted");      if (encryptedAttr != null)        encrypted = encryptedAttr.Value;      appSettings = appSectionNode.SelectNodes("appSetting");      if (appSettings != null)      {//Loop through all the appSetting elements and add them to the arraylist        foreach(XmlNode appSetting in appSettings)        {          sname = appSetting.Attributes["key"].Value;svalue = appSetting.Attributes["value"].Value;          arrAppSetting.Add(sname, svalue);        }      }arrSettings.Add(new AppSection(name, arrAppSetting,encrypted));    }    //Return the constructed object to the caller    return arrSettings;  }}

In the above code, we basically loop through all the elements in the custom configuration section and add it to an array list of that contains all the settings in the form of AppSection objects. The AppSection class that is used to encapsulate every subsection in the custom configuration section is defined as follows:

public class AppSection{  private string _name;  private NameValueCollection _appSettings;  private string _encrypted;public AppSection(string name, NameValueCollection appSettings, string encrypted)  {    _name = name;    _appSettings = appSettings;    _encrypted = encrypted;  }  public string Name  {    get    {      return _name;    }  }  public string GetValue(string key)  {    string keyValue = null;    if ( _appSettings !=null)    {//Get the corresponding value from the NameValueCollection      keyValue = _appSettings[key.Trim()];      if (_encrypted == "true")      {  byte[] encryptedText = Encoding.ASCII.GetBytes(keyValue);        Decryptor dec = new Decryptor();        byte[] plainText = dec.Decrypt(encryptedText);        keyValue = Convert.ToBase64String(plainText);      }    }                          return keyValue;  }    }

The GetValue method in the AppSection class is where the check for decryption is performed. If the encrypted attribute returns true, then the method decrypts the encrypted settings by invoking the Decrypt method of the Decryptor class.

Encryption and decryption of configuration settings

As the name suggests, the Visual C# class library project named Encryption provides the functionality to encrypt and decrypt configuration settings. For example, we might want to encrypt the value while storing the connection string within the configuration file and then decrypt that information at runtime to connect to the appropriate backend database. For performing encryption and encryption, we use the Triple Data Encryption Standard algorithm that is implemented by the System.Security.Cryptography.TripleDES class.

All the encryption related classes are implemented in the class library project Encryption. There are four classes in this project named Encryptor, Decryptor, EncryptTransformer, and DecryptTransformer that provide this functionality. Again the code for this reusable component can be downloaded along with the support material for this article.

Utilities Class Library

In this component, we encapsulate the commonly performed operations in the form of helper classes. The functionalities provided by these helper classes are defined as follows:

  • Sending mails using SMTP service — This is accomplished using the classes contained in the System.Web.Mail namespace.
  • Raising SoapExceptions — Exposes helper methods that allow us to raise SoapExceptions in a standardized and consistent manner.
  • Performing XML transformations by applying XSL stylesheets — This is implemented using the classes contained in System.Xml and System.Xml.Xsl namespaces.

Default Configuration Settings for the ASP.NET Web UI and Web Service Applications

Since we are creating this base template for creating web-based E-commerce applications, we can pre-define some of the common parameters used by our web application. For example, since we want our web application to be scalable, we can enforce the use of SQL Server based session state management capabilities by pre-populating the sessionState element in the web.config file with appropriate values.

Let us start by creating a new ASP.NET web application named WebUI, selecting Visual C# as the language of choice. The following list identifies the configuration parameters that we want to pre-populate when our template is used to create an E-commerce application.

  • Session state management — For storing session state, we will use the SQL Server based session state management capabilities provided by ASP.NET. To accomplish this, we will need to add the following settings.
    <sessionState     mode="SQLServer"    sqlConnectionString="data source=testsource;uid=uid;password=password"    cookieless="false"     timeout="20" />

  • Exception management application block related settings — The exception management block supplied by Microsoft makes it possible to manage exception-logging capabilities by having entries in the web.config file. In our application, since we always want to log exceptions in a separate event log (named AppEventLog), we will add the following settings.
    <exceptionManagement mode="on">    <publisher assembly="Microsoft.ApplicationBlocks.ExceptionManagement" type="Microsoft.ApplicationBlocks.ExceptionManagement.DefaultPublisher" logname="AppEventLog" applicationname="Custom Distributed App Template" /></exceptionManagement>

  • Custom configuration section handling related sections — Each custom configuration section is represented by a section named appConfigSection.
    <configuration>   <configSections><section name="appConfigSection"             type="Distr.AppFramework.ConfigurationHandler.ApplConfigSectionHandler,ConfigurationHandler"></section>    </configSections> ...  <appConfigSection>  <appSection name="exampleSection" encrypted="false"><appSetting key="key1"   value="value1"></appSetting>  </appSection>  </appConfigSection></configuration>

  • Common page to redirect to, when an exception occurs in our application — This is set to ErrorPage.aspx
    <customErrors   defaultRedirect="Common/ErrorPage.aspx"   mode="RemoteOnly" />

  • Authentication model for the web application — We will set the authentication model to forms based authentication by using the following setting.
    <authentication mode="Forms">  <forms name="DistributedAppAuth" loginUrl="Login.aspx" path="/"></forms></authentication>

As you can see from the above setting, we are also pre-defining the login page as Login.aspx.

For the ASP.NET web service application, since we dont our web service to be accessible over HTTP Get and HTTP Post (except for testing purposes), we will add the following entries directly under system.web element.

<webServices>  <protocols>    <remove name="HttpPost" />    <remove name="HttpGet" />  </protocols></webServices>

So far, we have seen the different building blocks that will provide the core foundation for building the enterprise template. In the Part-2 of this article, we will see customize the enterprise template and add these building blocks as part of the template.

Source Code

Download Source Code: – 95 kb

About the Author

Thiru has six years of experience in architecting, designing, developing and implementing applications using Object Oriented Application development methodologies. He also possesses a thorough understanding of software life cycle (design, development and testing).

He is an expert with ASP.NET, .NET Framework, Visual C#.NET, Visual Basic.NET, ADO.NET, XML Web Services and .NET Remoting and holds MCAD for .NET, MCSD and MCP certifications.

Thiru has authored numerous books and articles. He can be reached at

# # #

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories