Design Issues & Architectures in .NET Application Development

The design and structure of an application is more important, as the technical details of its implementation. Upon developing any new project, we should settle on the issues such as the Technologies to use, Database Engine to employ, the Physical Architecture of the application etc. This article will provide some idea on the designing issues in a .NET application.

The following are some of the design issues for an enterprise application:

• Which Language to choose?
• Which Database Engine to employ?
• Web or Desktop User Interface, and mainly the
• Physical Architecture

Which Language to choose?

A wide variety of .NET complaint Languages are available. The Language should be selected in a way that it should let us accomplish the tasks needed by the application.

Consider a GUI intense application or standard business application, in both the cases we could go for a language which supports good User Interface features and IDE s for RAD (Rapid Application development) such as Visual Basic or Visual C#.

Similarly, consider a gaming application or an application which requires intense communication with the underlying hardware of the machine. In such a case we will certainly go for a Language such as Visual C++ and not VB. But the fact is C# will suit both the cases.

Which Database Engine to employ?

This factor depends upon the following:

• The Database engine, the Client might already have in-house.
• The amount of Data
• The ease of integration with other Databases or a different server
• The nature of Data to be stored

Web or Desktop User Interface

Some applications such as E-Commerce, Online shopping carts, Corporate Web Sites and essentially enterprise applications for remote users who have Internet access, clearly need a Web Interface and some need a Desktop User Interface; but there are other applications which make us think for a while before selecting the appropriate User Interface required.

Let's see the basic issues that will help to choose the suitable User Interface.

The application needs a Web UI if 

• Users are located in remote sites and have access to the Internet
• The application is a Business to Business (B2B) application
  • Application to application communication is easier across platforms and devices which could be achieved seamlessly when Web Services are implemented. 
• The application is a Business to Consumer (B2C) application
  • Web Applications could reach more rather than a desktop application which could cover only a LAN or it should be distributed thru' CD's and must be installed in each and every PCs.
• The amount of data entered and the number of fields on the screen are fairly minimal
  • If there are so much of data to be entered by the user, it will in turn require rich set of User controls, Forms and Dialogs which is facilitated by Desktop UI - Win Forms rather than Web Forms.
• Limited User Interface is what required 
• The amount of data to be displayed on the screen is minimal
  • Performance can be slower in a Web application because the data and the screen design are sent from the server each time an HTML document is requested. In a desktop application, the interface is rendered locally once, and just the data is brought across a fast network connection.
• Each user "own" their data
  • In this case, it could be easy to maintain the sessions and cookies
• Users like to scroll through the data, as opposed to tabbing through data  
• Need to have a lot of lengthy screens to be scrolled down 
• Deployment costs should be minimal
• Upgrade costs should be minimal
  • Web UI provides a centralized application deployment and upgrading thus reducing the deployment and upgrading costs.
• Need to be upgraded frequently

The Web UI also allows using standard HTML interface elements. Some applications take a lot of processing power. Instead of having to update each individual workstation, we can increase the power of the central server.

The application needs a Desktop UI if

Physical Architecture

The following are some of the possible architectures for a .NET application

• 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

Two-Tier Application Architecture

Client Application uses ADO.NET to directly communicate with the Database Server.



Fig1. Two-Tier Architecture

This type of architecture is suitable for small applications with very less user interfaces and simple business logic.

How ever, this will not be helpful for an enterprise development environment.

Development Technique

• Controls in the forms are directly bound to data sets using data binding.
• Code can also be written to access the database and load data manually into controls.
• All business rule come along with the UI.

Three-Tier Application Architecture using XML Web Services

All SQL resides in the Web Services, Datasets are built on the server and the data is retrieved from the store and returned as an XML stream to the client, where they can be rebuilt into datasets.

This architecture is appropriate for both Web and Win Applications.

This type of architecture will best suit when we need the richness of a desktop application but users connect to it from many different locations and access the data across an HTTP interface.



Fig2. Three-Tier Architecture using Web Services

Features

• Quick and easy development
• Since the Database access logic has been separated as a web service, the db access layer can be updated centrally
• Thus minimizes maintenance costs
• Since the business rules are not separated from the UI, Updating or modifications become very cumbersome. i.e., in any such case of modifications, all clients must be updated.
• Client must have internet access (Since Web Services are involved)

Thus this architecture goes well to some extent for an Internet scenario.

Three-Tier Application Architecture using .NET Remoting

All SQL resides within the component called through the Remoting service and the datasets are built on the server and returned as an XML stream to the client where they can be re-built into datasets. Code can also be written to load data returned from the Remoting component, manually onto the controls on the forms.

This architecture is appropriate for an application that must be distributed between computers on a LAN. Working within a LAN environment, .NET Remoting can be used to wrap up the data access layer.

Thus this architecture goes well with an Intranet scenario.



Fig3. Three-Tier Architecture using .NET Remoting

Features

• Quick and easy development
• Since the Database access logic is a separate layer, the db access layer can be updated centrally
• Thus minimizes maintenance costs
• Since the business rules are not separated from the UI, Updating or modifications become very cumbersome. i.e., in any such case of modifications, all clients must be updated.
• Users can run this application from anywhere they have connectivity to the LAN or WAN.

Logical N-Tier Architecture

This architecture consists of the front end, a business rule component, and a data layer component. This is the best approach which works equally well for all types of .NET applications.



Fig4. N-Tier Architecture

Features

• Centralizes business rules into a separate layer
• Any of the components/layers can moved to any machine thus improving scalability and centralization
• Development takes a little longer which is not an issue exactly because its going to be fruitful finally

Logical N-Tier Architecture using Web Services

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.



Fig5. N-Tier Architecture using Web Services

This is the best approach, in which case, the data layer is centralized and the client can be web or windows application.