Designing a .NET Application

Upgrading to Microsoft .NET

Paul D. Sheriff
PDSA, Inc.

April 2002

Summary: An overview of the differences between typical physical architectures that have proven useful in .NET applications. Each architecture description includes basic guidelines on appropriate scenarios for use, implementation options, advantages, and disadvantages. Describes two-tier, three-tier, and n-tier applications. (14 printed pages)

Note The application design issues introduced in this article are covered in greater depth in the Building Distributed Applications with .NET section of MSDN®.

Objectives

Explore typical architectures for Microsoft® .NET applications.

Look at the pros and cons for development within each architecture.

Assumptions

You are familiar with .NET development including Web and desktop development.

You are familiar with programming concepts, including classes and attributes.

You are familiar with a variety of architectures, including multi-tier and multi-server structures.

Contents

Two-Tier Application Architecture
Three-Tier Application Using an XML Web Service
Three-Tier Application Using .NET Remoting
Logical N-Tier Applications
N-Tier Application Using an XML Web Service
Other N-Tier Application Techniques
Migrating a Visual Basic 6.0 N-Tier Application
Conclusion

Two-Tier Application Architecture

A typical two-tier application is a client application using ADO.NET communicating directly with a database server, like Microsoft SQL Server™ (see Figure 1). There are no intervening layers between the client application and the database other than ADO.NET. For more information on ADO.NET, see the .NET Framework documentation, other articles in this series or use the MSDN search engine.

Figure 1. A two-tier application has a client application and a data store, such as Microsoft SQL Server

When to Use a Two-Tier Architecture

A two-tier application is appropriate for a small application that does not have a lot of forms, or perhaps no forms at all. It may also be appropriate for prototypes where the final version of the application uses one of the other n-tier techniques described in this article. A two-tier application is not well suited, however, to an enterprise environment, because development and maintenance time and costs can become unmanageable.

Typical Implementation Options

There are several techniques you can use to develop a two-tier application. All use ADO.NET with a client interface, such as a desktop or Web-based application, and a database, such as SQL Server. Ideas for how to approach the architecture of a two-tier application include:

· Use data binding techniques to connect an ADO.NET dataset directly to controls.

· Write code that accesses ADO.NET objects to load data manually into controls on your user interface.

· Use a combination of the above two techniques.

· Code business rules directly on the forms with any of the above techniques.

Advantages

A two-tier application has the following advantages:

Development can be quick and easy because you can use data binding to connect an ADO.NET dataset directly to many of the controls used to build the user interface. This helps you get the basic functions of an application up and running quickly.

You can see an application's entire code by looking in just your forms. There is no need to look at both your forms and into another component to see the code.

Disadvantages

The two-tiered application development method has the following disadvantages:

All business rules are contained in the front-end code. As a result, if you need to change a business rule, all clients must be updated. Unless you have an automated update approach, this can be a maintenance nightmare. Of course, if you use SQL Server, you can put some business rules into stored procedures to decrease maintenance time and costs.

Although SQL can provide a level of abstraction between the database structure and the rest of the application, field names are often hard-coded into the source code or control properties. If you change a field name, you have to find and replace every occurrence in your application. When data binding is involved, you also have to check all forms and change properties.

A lot of code—SQL statements and business rules, for example—is often repeated throughout the application because various forms use some of the same tables. This makes maintaining this type of application very difficult because if you need to change the name of a table or a field, you have to change it in multiple places. It also requires extra regression testing in multiple locations.

Changing the code used to load data into a dataset is more difficult if the source of that data changes. For example, if you use a text file to store your data and then switch to SQL Server, the access method is quite different. In addition, many areas will require code changes in order to load data into your application's dataset.

Three-Tier Application Using an XML Web Service

Another design option is to use an XML Web service to separate the database's access to another component that returns the data to the front-end application. Figure 2 illustrates this design option.

For more information on developing three-tier applications using XML Web services, use the MSDN search engine.

Figure 2. Use an XML Web service to separate the database layer from the front-end code

When To Use This Technique

A three-tier application using an XML Web service is appropriate for either a Web-based or Microsoft Windows® application. This technique comes in handy when you need the richness of a desktop application, but users connect to it from many different locations and access the data across an HTTP interface.

Typical Implementation Options

You will most likely use the following development techniques to create a three-tiered/XML Web service application:

· All SQL resides within the XML Web service. Datasets are built on the server and returned as an XML stream to the client where they can be rebuilt into datasets.

· Datasets returned from the XML Web service can be bound directly to the controls on the forms.

· Datasets returned from the XML Web service can be used to manually load data into the various controls on the forms.

· All business rules are coded directly on the forms.

Advantages

A three-tier application using an XML Web service has the following advantages:

Development can be quick and easy because you can use data binding to connect an ADO.NET dataset directly to many of the controls used to build the user interface. This helps you get the basic functions of an application up and running quickly.

Users can run your application from anywhere they have connectivity to the Internet (or intranet).

Database access is separated to its own component so the front-end code does not have SQL embedded in it.

Connection information is maintained only on the XML Web service, again minimizing client machine maintenance.

The database access layer can be updated in a central location. There is no need to redistribute components to the client if you make a simple code change to this layer.

Disadvantages

The disadvantages to this design are essentially the same as for a typical two-tier application, since you have not separated the business rules, just the data layer. You also have not abstracted the column names in the tables into a class—something you will learn about in the next section.

All business rules are contained in the front-end code. As a result, if you need to change a business rule, all clients must be updated. Unless you have an automated update approach, this can be a maintenance nightmare. Of course, if you use SQL Server, you can put some business rules into stored procedures to decrease maintenance time and costs.

All field names are hard-coded into either the source code or control properties. If you change a field name, you have to find and replace every occurrence in your application. When data binding is involved, you also have to check all forms and change properties.

Performance across an HTTP interface is slower than a direct database connection.

If the user does not have Internet (or intranet) access, the application is unusable.

Three-Tier Application Using .NET Remoting

This type of application architecture is almost exactly the same as the three-tier application using an XML Web service. The only difference is that you use .NET Remoting instead of an XML Web service to wrap up the data access layer. Figure 3 illustrates this design option.

For more information on .NET Remoting, see the other articles in this series or use the MSDN search engine.

Figure 3. Working within a LAN environment, you can use .NET Remoting to wrap up the data access layer

When to Use the Three-Tier .NET Remoting Technique

A three-tier application using .NET Remoting is appropriate for an application 'that must be distributed between computers on a LAN. This may be for business reasons or because the cost of the work involved justifies the cost of the network call.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application.

All SQL resides within the component called through the Remoting service. Datasets are built on the server and returned as an XML stream to the client where they can be re-built into datasets.

Datasets returned from the Remoting component are bound directly to the controls on your forms.

Datasets returned from the Remoting component are used to load data manually into the different controls on your forms.

All business rules are coded directly on the forms.

Advantages

A three-tier application using .NET Remoting has the same basic advantages as a three-tier application using an XML Web service.

Three-tiered applications are quick and easy to program because you can use data binding to connect an ADO.NET dataset directly to many of the controls that you use to build the user interface. This helps you get the basic functionality of an application up and running quickly.

Users can run this application from anywhere they have connectivity to the LAN or WAN.

Database access is separated to another component so the front-end code does not have any SQL embedded in it.

The database access layer can be updated in a central location. There is no need to redistribute components to the client if you make a simple code change in this component.

Note This advantage is true for all n-tier architectures.

Disadvantages

The disadvantages of this type of three-tier design are the same as those described when using an XML Web service.

All business rules are contained in the front-end code. As a result, if you need to change a business rule, all clients must be updated. Unless you have an automated update approach, this can be a maintenance nightmare. Of course, if you use SQL Server, you can put some business rules into stored procedures to decrease maintenance time and costs.

All field names are hard-coded into either the source code or control properties. If you change a field name, you have to find and replace every occurrence in your application. When data binding is involved, you also have to check all forms and change properties.

Data transfer from one component to another across a network is slower than a direct database connection. .NET Remoting in an intranet scenario can perform better than an XML Web service. You are less likely to use .NET Remoting in an Internet scenario.

Setting up this type of application is a little more complicated than either a two-tier application, or one that uses an XML Web service.

Logical N-Tier Applications

The best approach to building an application using .NET is to separate all logical processes into discrete classes. In a typical business application, this generally involves a business rule component, a data layer component, and the front-end code that uses these components. Figure 4 illustrates this approach.

For more information on designing an n-tier application, see the other articles in this series or use the MSDN search engine.

Figure 4. Break up business processes into separate classes to make your application easier to create and maintain

When to Use an N-Tier Architecture

Using a logical n-tier development strategy is appropriate for all types of applications. It works equally well in small, medium, and large applications, and with both desktop and Web applications.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application:

Create the front-end user interface using either Windows Forms or Web Forms.

Create the business rule component as a separate Class Library project.

Create a data layer component as a separate Class Library project. This data layer uses classes to wrap up access to each table. Typed datasets should be used; they provide the flexibility of the dataset class and strong typing for each column in the tables.

Advantages

A logical n-tier application has the following advantages:

Centralizes business rules into a component that is easy to create, use, and re-use. This makes development and maintenance easier.

Provides a high-level language in which to develop business rules, as opposed to using stored procedures and limited SQL language for business rule checks.

Centralizes the data access into a component. This means less repeated code throughout your application; each form that needs to access a specific table always uses the same component.

If you use typed datasets, you get the benefit of looking up column names using IntelliSense instead of having to remember them.

Centralized data access routines help with maintenance, since changes to any data access routine need be made only once.

Provides the flexibility to separate components onto different physical machines at any time. This helps with scalability and better centralization of code.

Disadvantages

A logical n-tier application has only two significant disadvantages:

Development takes a little longer because you must build separate components.

There are a few more components to track. This makes this development method a little more complicated to understand for new programmers.

N-Tier Application Using an XML Web Service

Figure 5 shows an example of how you might take a logical n-tier application design and split it across multiple machines. In this diagram, you can see that an XML Web service is used to access the data layer. The typed dataset is returned across the HTTP layer to the business rule layer. The client application can then consume the dataset for the user interface presentation of the data.

Figure 5. Separate your business processes onto separate machines to help with deployment and maintenance

When to Use This Technique

The n-tier XML Web service type of application design is appropriate when you need the richness of a desktop application, but users may be connecting from many remote locations and need to get the data across an HTTP interface. Keeping the business rules on the client side helps with network traffic, but can impose some maintenance update hassles if the rules change frequently. Because .NET is able to copy over new DLLs without registration, these issues are not as severe as they used to be in earlier technologies.

This scenario can also be useful for Web-based applications where the data might be provided by one Web server, but displayed by another Web application on another Web server.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application. 'These techniques are the same as those of the logical n-tier application.

Create the front-end user interface using either Windows Forms or Web Forms.

Create the business rule component as a separate Class Library project.

Create a data layer component as a separate Class Library project. This data layer uses classes to wrap up access to each table. Typed datasets should be used; they provide the flexibility of the dataset class and strong typing for each column in the tables.

Advantages

An n-tier application using an XML Web service has several advantages, many of which are' the same as those of the logical n-tier application.

Centralizes business rules into a component that is easy to create, use, and re-use. This makes development and maintenance easier.

Provides a high-level language in which to develop business rules, as opposed to using stored procedures and limited SQL language for business rule checks.

Centralizes the data access into a component. This means less repeated code throughout your application; each form that needs to access a specific table always uses the same component.

If you use typed datasets, you get the benefit of looking up column names using IntelliSense instead of having to remember them.

Centralized data access routines help with maintenance, since changes to any data access routine need be made only once.

Provides the flexibility to separate components onto different physical machines at any time. This helps with scalability and better centralization of code.

Added benefit: Centralized data access layer.

Added benefit: Application scalability—you can add a Web farm to handle heavy loads of user requests to the database.

Added benefit: Users can connect over the Internet and still access the data from a desktop or Web-based application.

Disadvantages

The n-tier application using an XML Web service development method has a few disadvantages. Most of these disadvantages are the same as those described when using the logical n-tier application development scenario.

Development takes a little longer because you must build separate components.

There are a few more components to track. This makes this development method a little more complicated to understand for new programmers.

If the XML Web service is not functioning, the application is unusable.

Other N-Tier Application Techniques

Of course, there are many different techniques you could use to create an n-tier application. For example, you could use .NET Remoting to communicate from the client tier to the business rule tier, as illustrated in Figure 6.

Figure 6. You can use a combination of .NET Remoting and XML Web services to give your application the best scalability and maintainability

There are a variety of ways you can configure an n-tier application once you have developed it using n-tier techniques. You can combine any of the methods available in .NET to separate the tiers of an application.

Migrating a Visual Basic 6.0 N-Tier Application

Programmers have used n-tier techniques for many years in previous versions of Microsoft Visual Basic®. If you have existing COM components now, you can easily place a .NET wrapper around them. When you do this, you may have an architecture that looks like Figure 7.

For more information about using COM components from within .NET, see the other articles in this series or use the search engine at the MSDN Web site.

Figure 7. .NET makes it easy to interface with your old COM components

When to use the Visual Basic migration technique

This technique is ideal when you have a large code base of COM components that already contain your business rules and data access routines. This can lower your cost of entry into the .NET Framework because you leverage a lot of your existing code.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application:

Create the front-end user interface using either Windows Forms or Web Forms.

Set a reference to your old COM DLL. Microsoft .NET automatically creates a .NET wrapper around this DLL so you can access the properties and methods just like you would any .NET component.

If you are returning any ADO recordsets from this DLL, you will most likely want to turn them into a dataset—the easiest way to bind to the .NET controls.

Advantages

Using the .NET wrapper around a COM interface can speed up your development cycle by taking advantage of the new .NET features, while using existing code.

Disadvantages

Using a COM wrapper in .NET has the following disadvantages:

Performance will not be as good compared to code written entirely in .NET.

Additional code may be required to convert an ADO recordset to an ADO.NET dataset.

Conclusion

There are almost an infinite number of architectural variations you can use when developing .NET applications. The best ones are both easy to create and maintain. Of course, you will also want to look at other design goals, including scalability, reliability and manageability. Many of these topics are covered in other white papers that you can find on MSDN.

About the Author

Paul D. Sheriff is the owner of PDSA, Inc., a custom software development and consulting company in Southern California. Paul is the MSDN Regional Director for Southern California, the author of a book on Visual Basic 6 called Paul Sheriff Teaches Visual Basic, and has produced over 72 videos on Visual Basic, SQL Server, .NET and Web development for Keystone Learning Systems. Paul has co-authored a book entitled ASP.NET Jumpstart. Visit the PDSA, Inc. Web site (www.pdsa.com) for more information.

About Informant Communications Group

Informant Communications Group, Inc. (www.informant.com) is a diversified media company focused on the information technology sector. Specializing in software development publications, conferences, catalog publishing and Web sites, ICG was founded in 1990. With offices in the United States and United Kingdom, ICG has served as a respected media and marketing content integrator, satisfying the burgeoning appetite of IT professionals for quality technical information.

Copyright © 2002 Informant Communications Group and Microsoft Corporation

Technical editing: PDSA, Inc.