Web Application Architectures: Simple 2 Layer, Standard 3 Layer and Distributed 3 Layer

Abstract:

This article discusses three common web application architectures: Simple 2 Layer, Standard 3 Layer and Distributed 3 Layer. For each architecture, it gives an ASP.NET 2.0 sample implementaion with NBear framework.

Table of Contents:

1. Simple 2 Layer
2. Standard 3 Layer
3. Distributed 3 Layer
4. More about NBear
5. Get Source Code of NBear and All Samples
6. Summary

1. Simple 2 Layer

This is the simplest web application architecture (See Figure 1.1).

Figure 1.1

The presentaion layer directly calls the data access layer to read/write data in database.

A classic example of this architecture is used by most ASP applications, people use Transaction Scripts read/write data in database through ADO. In the ASP case, ASP is the Web Presentaion Layer, and ADO is the Data Access Layer.

Sample 1

To apply this architecture with NBear is super easy. Set connection strings in Web.config; create your website project and reference to the NBear framework .DLLs; use EntityGen tool (provided by NBear) to generate entities automatically; and then you can read/write data in databases for free. Here NBear.Data works as the Data Access Layer, which makes data accessing much easier than using ADO.NET directly. The implementation architecture is like figure 1.2.

Figure 1.2

Entities Definition are interface style entities code generated by NBear.Tools.EntityGen.exe. (You can manually write them or modify them based on the gerated code, as well.) Code 1.1 is some sample entities code of the simple sample:

Code 1.1 sample entities code of Simple 2 Layer
 1namespace NorthwindEntities
 2{
 3    //description:
 4
 5    //entities can be automatically generated by tool: NBear.Tools.EntityGen.exe
 6    //you can modify the generated code, set attributes to entity name or entity property to change entity/table,
 7    //property/column mapping and primary keys mapping.
 8
 9    public interface Categories : IEntity
10    {
11        [PrimaryKey]
12        int CategoryID { get; }
13        string CategoryName { get; set; }
14        string Description { get; set; }
15        System.Byte[] Picture { get; set; }
16    }
17
18    //
19
20    [Table(IsView = true)]
21    public interface Summary_nbsp_of_nbsp_Sales_nbsp_by_nbsp_Year : IEntity
22    {
23        System.DateTime ShippedDate { get; }
24        int OrderID { get; }
25        decimal Subtotal { get; }
26    }
27}

Notice, each entity is an interface inherited from NBear.Common.IEntity. An entity maps to a database table or view. Each property of entity maps to a database table column. Data column's read/write abilities are reflected by properties' get and set. You can add .Net Attributes (TableAttribute, ColumnNameAttribute and PrimaryKeyAttribute) to entities to change the default mapping. By default, the names of entity/table, property/column are same, you can change them taking advantage of these Attributes.

Connection strings can be set like Code 1.2 in Web.config (for windows form application, of couse you should set them in App.config).

Code 1.2 Web.config of Simple 2 Layer
 1<?xml version="1.0"?>
 2<configuration>
 3  <configSections>
 4    <!--Enable this if you want Url rewrite support, you should ensure NBear.Web.dll is refered.-->
 5    <!--<section name="UrlRewriteRules" type="NBear.Web.Modules.UrlRewriteRules, NBear.Web"/>-->
 6  </configSections>
 7  <appSettings>
 8    <add key="RootUrl" value="/website/"/>
 9  </appSettings>
10  <connectionStrings>
11    <add name="TestAccessDb" connectionString="Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Teddy\NBear\skeleton\Simple\website\App_Data\TestAccessDb.mdb" providerName="NBear.Data.MsAccess.AccessDbProvider"/>
12    <add name="Northwind" connectionString="Server=(local);Database=Northwind;Uid=sa;Pwd=sa" providerName="NBear.Data.SqlServer.SqlDbProvider"/>
13  </connectionStrings>
14  <system.web>
15    <compilation debug="true">
16      <assemblies>
17        <add assembly="System.Runtime.Serialization.Formatters.Soap, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
18      </assemblies>
19    </compilation>
20    <authentication mode="Windows"/>
21    <httpModules>
22      <!--Enable this if you want Url rewrite support, you should ensure NBear.Web.dll is refered.-->
23      <!--<add type="NBear.Web.Modules.UrlRewriteModule, NBear.Web" name="UrlRewriteModule"/>-->
24    </httpModules>
25  </system.web>
26    <!--Enable this if you want Url rewrite support, you should ensure NBear.Web.dll is refered.-->
27    <!--
28  <UrlRewriteRules>
29    <Rule key="^/Category/(.+).html" value="/Category.aspx?ID=$1" />
30    <Rule key="^/(.+).html" value="/$1.aspx" />
31    </UrlRewriteRules>
32  -->
33</configuration>

Ensuring your ASP.NET 2.0 website project referencing to NBear.Common, NBear.Data, and you can freely read/write data in database using NBear.Data.Gateway now. For easier to call gateways, in this sample we define a Gateways class in App_Code so that we can call gateways in it freely without adding "using NBear.Data" statement in each .cs files you want to call it. Code 1.3 is the Gateways.cs and Code 1.4 shows how to call gateway and read/write data in database. All return results may be strong type Enitity (Array). And you can apply transactions to queries through NBear.Data.Gateway.BeginTransaction() or you can use the new .Net 2.0 classes in System.Tansactions namespaces to realize transactions, too.

Code 1.3 Gateways.cs of Simple 2 Layer
 1/**//// <summary>
 2/// Init Database access gateways here
 3/// </summary>
 4public abstract class Gateways
 5{
 6    private Gateways()
 7    {
 8    }
 9
10    //description:
11
12    //connection strings for Northwind and TestAccessDb are set in Web.config file.
13    //NBear will automatically create a default gateway for the last connection string setting(in this case, it is the Northwind database), 
14    //you can visit the default gateway by NBear.Data.Gateway.Default property.
15    //you can call NBear.Data.Gateway.SetDefaultDatabase() to set any other database connection as default gateway.
16
17    //you can create new gateway by providing the connection string setting name(like in this case) or the database type and connection string
18    //or the assembly name and classname which implemented NBear.Data.DbProvider, 
19    //which is a abstract class defining all the basic db provider functions.
20
21    public static Gateway Northwind = new Gateway("Northwind");
22    public static Gateway TestAccessDb = new Gateway("TestAccessDb");
23}

Code 1.4 Default.aspx.cs of Simple 2 Layer
 1public partial class _Default : System.Web.UI.Page 
 2{
 3    protected void Page_Load(object sender, EventArgs e)
 4    {
 5        GridView1.DataSource = Gateways.Northwind.Select<NorthwindEntities.Products>(10, 2, null, null);
 6
 7        GridView2.DataSource = Gateways.TestAccessDb.SelectAll<TestAccessDbAccessEntities.User>();
 8
 9        DataBind();
10    }
11}

Is it easy enough as you can imagine? :)

2. Standard 3 Layer

The Standard 3 Layer architecture is the most common web application architecture. Figure 2.1 shows its structure.

Figure 2.1

The main difference from the Simple 2 Layer architecture is a new Domain/Service Layer is added. This layer includes resuable business domain logic and services. Separating this layer makes our code more reusable and easier to test. With Unit Testing tools, We can easily test code in this layer independently and automatically. When applying this architecture, for easier to manage/test code in this layer and to decouple the web presentaion layer from this layer, it is suggested to design services with interfaces. The following sample will show you how to do this and what's the benefits.

Sample 2

Let's see the implementaion architecture (see Figure 2.2) and compared with Sample 2.

Figure 2.2

Comparing it with sample 1, we can see the differences are 3 new components are added. Service Interfaces Definition is what I mentioned above that is the interfaces of services you want to provide. Services Implementaion of course are the code of implementing the service interfaces.

Which really interesting is the Service Factory. Service Factory is a factory used to produce services, you can pass the service interface to it and it returns you service interface implementaion. The Service Factory is provided by NBear.IoC component, it  is designed based on a service container (taking advantage of the Castle IoC container). As you can see in Figure 2.2, the web application layer only depends on the Service Factory, Service Interfaces Definition and the Entities Definition, which means you can use inversion of control to configurate service implementaions in configuration file (Web.config/App.config), and Service Factory will discover and load these implementaions at runtime and return to web presentaion layer. This kind of design decouples the web application layer from the service implementaions so that in team development, web presentaion layer development/testing and service development/testing can be synchronized and independent, which really saves costs.

Code 2.1 is a sample service interface, and Code 2.2 is the implementaion of the service interfaces. The Service Factory is initiated in ServiceFactory.cs (see Code 2.3) file under App_Code folder of website. Notice, it calls components in NBear.IoC. And in Default.aspx.cs (see Code 2.4), this is the same logic as sample 1, this time we uses service factory to create service and call services rather than reading data from database directly like code in sample 1. To be discovered by service container, service implementaions must be configurated in Web.config like Code 2.5.

Code 2.1 sample service interface
1namespace ServiceInterfaces
2{
3    public interface ISampleService : NBear.IoC.Service.IServiceInterface
4    {
5        NorthwindEntities.Products[] LoadAllProductsByPage(int pageSize, int pageNo);
6        TestAccessDbAccessEntities.User[] LoadAllUsers();
7    }
8}

Code 2.2 sample service interface implementaion
 1namespace ServiceImpls
 2{
 3    public class SampleServiceImpl : ServiceInterfaces.ISampleService
 4    {
 5        ISampleService Members#region ISampleService Members
 6
 7        public NorthwindEntities.Products[] LoadAllProductsByPage(int pageSize, int pageNo)
 8        {
 9            return Gateways.Northwind.Select<NorthwindEntities.Products>(pageSize, pageNo, null, null);
10        }
11
12        public TestAccessDbAccessEntities.User[] LoadAllUsers()
13        {
14            return Gateways.TestAccessDb.SelectAll<TestAccessDbAccessEntities.User>();
15        }
16
17        #endregion
18    }
19}

Code 2.3 ServiceFactory.cs
 1public abstract class ServiceFactory
 2{
 3    private ServiceFactory()
 4    {
 5    }
 6
 7    //description:
 8
 9    //You should use standard castle component decleration schema to define service interface impls in Web.config
10    //for more information about castle project and its IoC Configuration, 
11    //please visit: http://www.castleproject.org/index.php/IoC:Configuration
12
13    private static NBear.IoC.Service.ServiceFactory factory = new NBear.IoC.Service.ServiceFactory(new SimpleServiceContainer());
14
15    public static IServiceInterfaceType GetService<IServiceInterfaceType>()
16        where IServiceInterfaceType : IServiceInterface
17    {
18        return factory.GetService<IServiceInterfaceType>();
19    }
20}

Code 2.4 Default.aspx.cs
 1public partial class _Default : System.Web.UI.Page 
 2{
 3    protected void Page_Load(object sender, EventArgs e)
 4    {
 5        ServiceInterfaces.ISampleService service = ServiceFactory.GetService<ServiceInterfaces.ISampleService>();
 6
 7        GridView1.DataSource = service.LoadAllProductsByPage(10, 2);
 8
 9        GridView2.DataSource = service.LoadAllUsers();
10
11        DataBind();
12    }
13}

Code 2.5 Web.config
 1<?xml version="1.0"?>
 2<configuration>
 3  <configSections>
 4    <!--Enable this if you want Url rewrite support, you should ensure NBear.Web.dll is refered.-->
 5    <!--<section name="UrlRewriteRules" type="NBear.Web.Modules.UrlRewriteRules, NBear.Web"/>-->
 6    <section name="castle" type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
 7  </configSections>
 8  <castle>
 9    <components>
10      <!--You can use standard castle component decleration schema to define service interface impls here-->
11      <component id="sample service" service="ServiceInterfaces.ISampleService, ServiceInterfaces"  type="ServiceImpls.SampleServiceImpl, ServiceImpls" />
12    </components>
13  </castle>
14  <appSettings>
15    <add key="RootUrl" value="/website/"/>
16  </appSettings>
17  <connectionStrings>
18    <add name="TestAccessDb" connectionString="Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Teddy\NBear\skeleton\Simple\website\App_Data\TestAccessDb.mdb" providerName="NBear.Data.MsAccess.AccessDbProvider"/>
19    <add name="Northwind" connectionString="Server=(local);Database=Northwind;Uid=sa;Pwd=sa" providerName="NBear.Data.SqlServer.SqlDbProvider"/>
20  </connectionStrings>
21  <system.web>
22    <compilation debug="true">
23      <assemblies>
24        <add assembly="System.Runtime.Serialization.Formatters.Soap, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
25      </assemblies>
26    </compilation>
27    <authentication mode="Windows"/>
28    <httpModules>
29      <!--Enable this if you want Url rewrite support, you should ensure NBear.Web.dll is refered.-->
30      <!--<add type="NBear.Web.Modules.UrlRewriteModule, NBear.Web" name="UrlRewriteModule"/>-->
31    </httpModules>
32  </system.web>
33    <!--Enable this if you want Url rewrite support, you should ensure NBear.Web.dll is refered.-->
34    <!--
35  <UrlRewriteRules>
36    <Rule key="^/Category/(.+).html" value="/Category.aspx?ID=$1" />
37    <Rule key="^/(.+).html" value="/$1.aspx" />
38    </UrlRewriteRules>
39  -->
40</configuration>

3. Distributed 3 Layer

Now we come to the distributed one. Do not breathe too heavy when seeing the word distributed. It doesn't mean complexity and hard to understand all the time, no mather in this article or in other system. Distributed doesn't means different business logic. The only difference that distributed application architecture has from non-distributed architectures is it needs some gumwater to let service implementaions deployed in different servers to adhere together. So, what I want to say is, if we have a bottle of nice (correct and suitable is enough, do not believe advertisements until you have tried by your hand) gumwater, distributed things will be as easy as non-distributed ones. I'll show you in the later distributed sample 3 in this article.

First let's begin with the common web distributed application architecture(see Figure 3.1).

Figure 3.1

Notice, difference is at the domain/service layer. Service implementaions now not only deployed on a single server. They are deployed on several servers. So we need a service factory to manage these service implementaions for us. The service factory is resposible for locating the service implementaions and decoupling the caller of service factory from service implementaions. See it is really similar to the service factory we created for only local services in sample 2. Can the service factory/service container provided by NBear.IoC deal with distributed service implementaions rather than local service implementaions only? You can guess the result -- Yes, of course. Even not only there is no need to change any web presentaion layer code where calling services, nor there is no need to change any service implementaions code. If you are using NBear, you can easily instance a service MQ server (build-in), split service implementaions to several hosts which can be deployed on different servers. With little little effort, your application become distributed. Let's see the implementaion architecture in Figure 3.2.

Figure 3.2

See, comparing to sample 2's architecture, the only difference is now service implemtaions not only deployed on a single server. How much modification of code need to make?
First, we need a service MQ Server. A service MQ is used to manage all the service requests and responses. There is a MemoryServiceMQ defined in NBear.IoC, if you want, you can implement your Service MQ (implement IServiceMQ interface) to using MSMQ, ActiveMQ or any commercial MQs yourself and substitute it for the build-in lightweight MemoryServiceMQ. Although MemoryServiceMQ is correct and suitable enough for most system I think. Code 3.1 is a simple service MQ server based on .Net remoting. (Now NBear only contains the .Net remoting broker, in the futher, it will provides more brokers. In fact it is really not so hard to implement brokers such as standard socket, web service or XML-RPC. I will talk about them in futher articles.)

Code 3.1 ServiceMQServer
 1namespace ServiceMQServer
 2{
 3    class Program
 4    {
 5        static void Main(string[] args)
 6        {
 7            string serverAddress = System.Configuration.ConfigurationManager.AppSettings["ServerAddress"];
 8            int serverPort = int.Parse(System.Configuration.ConfigurationManager.AppSettings["ServerPort"]);
 9            RemotingChannelType protocol = System.Configuration.ConfigurationManager.AppSettings["ServerAddress"].ToUpper() == ("HTTP").ToUpper() ? RemotingChannelType.HTTP : RemotingChannelType.TCP;
10
11            MemoryServiceMQ mq = new MemoryServiceMQ();
12            mq.OnLog = new LogHandler(Console.WriteLine);
13            RemotingServiceHelper rh =
14                new RemotingServiceHelper(protocol, serverAddress, serverPort, new LogHandler(Console.WriteLine));
15            rh.PublishServiceInstance("MMQ", typeof(IServiceMQ), mq, System.Runtime.Remoting.WellKnownObjectMode.Singleton);
16
17            Console.WriteLine("Press any key to exit and stop server");
18            Console.ReadLine();
19        }
20    }
21}

In the code, we can see, it easily instanced a MemoryServiceMQ object and publish it to HTTP with specified address and port taking advantage of .Net Remoting support. NBear.Net.Remoting contains some helper classes to make calling .net remoting components easier, see RemotingServiceHelper class which is used in this clip of code. That's all for the service MQ server.

Next, we move the service implementaions configuration from Web.config to some service hosts. Code 3.2 is a simple service host whose only resposibility is register service implementaions to service MQ server. The same service implementaions configuration now are in the host application's App.config (see Code 3.3).

Code 3.2 ServiceHost
 1namespace ServiceHost
 2{
 3    class Program
 4    {
 5        static void Main(string[] args)
 6        {
 7            string serverAddress = System.Configuration.ConfigurationManager.AppSettings["ServerAddress"];
 8            int serverPort = int.Parse(System.Configuration.ConfigurationManager.AppSettings["ServerPort"]);
 9            RemotingChannelType protocol = System.Configuration.ConfigurationManager.AppSettings["ServerAddress"].ToUpper() == ("HTTP").ToUpper() ? RemotingChannelType.HTTP : RemotingChannelType.TCP;
10
11            IServiceMQ mq = new RemotingClientHelper(protocol, serverAddress, serverPort, 0, new LogHandler(Console.WriteLine)).GetClientInstance<IServiceMQ>("MMQ");
12            IServiceContainer container = new SimpleServiceContainer(mq, new LogHandler(Console.WriteLine));
13
14            Console.WriteLine("Press any key to exit and stop host");
15            Console.ReadLine();
16        }
17    }
18}

Code 3.3 App.config
 1<?xml version="1.0" encoding="utf-8" ?>
 2<configuration>
 3  <configSections>
 4    <section name="castle"
 5        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
 6  </configSections>
 7  <castle>
 8    <components>
 9      <!--You can use standard castle component decleration schema to define service interface impls here-->
10      <component id="sample service" service="ServiceInterfaces.ISampleService, ServiceInterfaces" type="ServiceImpls.SampleServiceImpl, ServiceImpls"/>
11    </components>
12  </castle>
13  <connectionStrings>
14    <add name="TestAccessDb" connectionString="Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Teddy\NBear\skeleton\Simple\website\App_Data\TestAccessDb.mdb" providerName="NBear.Data.MsAccess.AccessDbProvider"/>
15    <add name="Northwind" connectionString="Server=(local);Database=Northwind;Uid=sa;Pwd=sa" providerName="NBear.Data.SqlServer.SqlDbProvider"/>
16  </connectionStrings>
17  <appSettings>
18    <add key="Protocol" value="HTTP"/>
19    <add key="ServerAddress" value="127.0.0.1"/>
20    <add key="ServerPort" value="8000"/>
21  </appSettings>
22</configuration>

There is only a final place need to modify, that is the ServiceFactory.cs of website, we should modify it to discover service from service MQ server. The interfaces for service caller is exact same, what we need to do is to get the Service MQ published by service MQ server through .Net Remoting channel just like what we do in Service Host application (see Code 3.4).

Code 3.4 ServiceFactory.cs
 1public abstract class ServiceFactory
 2{
 3    private ServiceFactory()
 4    {
 5    }
 6
 7    //description:
 8
 9    //You should use standard castle component decleration schema to define service interface impls in Web.config
10    //for more information about castle project and its IoC Configuration, 
11    //please visit: http://www.castleproject.org/index.php/IoC:Configuration
12
13    private static NBear.IoC.Service.ServiceFactory factory;
14
15    public static IServiceInterfaceType GetService<IServiceInterfaceType>()
16        where IServiceInterfaceType : IServiceInterface
17    {
18        if (factory == null)
19        {
20            string serverAddress = System.Configuration.ConfigurationManager.AppSettings["ServerAddress"];
21            int serverPort = int.Parse(System.Configuration.ConfigurationManager.AppSettings["ServerPort"]);
22            RemotingChannelType protocol = System.Configuration.ConfigurationManager.AppSettings["ServerAddress"].ToUpper() == ("HTTP").ToUpper() ? RemotingChannelType.HTTP : RemotingChannelType.TCP;
23
24            IServiceMQ mq = new RemotingClientHelper(protocol, serverAddress, serverPort, 0, null).GetClientInstance<IServiceMQ>("MMQ");
25            IServiceContainer container = new SimpleServiceContainer(mq, null);
26
27            factory = new NBear.IoC.Service.ServiceFactory(container);
28        }
29
30        return factory.GetService<IServiceInterfaceType>();
31    }
32}

 

Well, no other modification is needed. If you visit the Default.aspx of the website, you can see it runs exactly the same as Sample 2 and Sample 1. Let's go through the developers of this distributed's work when developing this application again to see is there any effort compared with sample2. Designing website is same, generating entities is some, defining service interfaces is same, implementing services is same... See, except very little modification for publishing and accessing the remote service MQ instead of the local one in sample2, everything is completely same. Is distributed application easy? Yes it is the gumwater's contribution, right? :)

4. More about NBear

Following is the official description of NBear:

A rapid/High Performance/Distributed application development framework based on .NET 2.0.
V2 of NBear is a big refactor and enhancement from V1. V2 reserves the strenths of V1 and
brings new flexible architecture. V2 focuses on not only RAD but also high performance and
scalability to make people's development life easier. V2 try hard to lead a nice development
process. That is to rapidly (Configless) develop application core functions and to append
performance ehancement/adjustment through additional configuration and build-in helper tools
later.

License: BSD
Copyright: 2005-2006 Ilungasoft.com/teddy.cn
Contact: Teddy (shijie.ma(at)gmail.com)
Blog: http://sf.net/projects/nbear

5. Get Source Code of NBear and All Samples

You can download the latest version of NBear from http://sf.net/projects/nbear, when writing this article, the latest version of NBear is V2.0.0. The downloaded zip file contains all the source code of NBear components and all the source code of sample 1-3 discussed in this article. These samples are located at the skeleton folder. I suggest you reference or directly begin from a copy of one of this three skeleton sample for your own development based on NBear.

6. Summary

In this article, we discussed 3 common web application architectures and sample implementaions for them based on NBear framework. Although application architectures discussed are all about web application, it should be similar for other type of applications, such as windows form application. Rename "web presentaion" to "winform presentaion" and Web.config to App.config, then most things are same enough.

Thanks for read from top to this bottom line. With best wishes.