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

Need to be connected to any special hardware
Need Drag-and-Drop support
It is a gaming or CAD, CAM application which needs direct communication with the hardware
Need much richer set of User Controls
Deployment of the system can be done through a network, by distributing CDs, or using push servers
Upgrades can be done through a network, by distributing CDs, or using push servers

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.

Features

Development is quick and easy
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.
When there is any change in the database or the field names the whole code should be altered. Changing the code used to load data into a dataset is much more difficult.

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.

3 Comments

Join the conversation! Your thoughts help the community grow.

Annie Calvert14y agoedited
This article really gives a way out from a problem which i was facing from a long time.thanks for the much needed help. http://www.dapfor.com/en/net-suite/net-grid/features/performance
Sarabjit Singh15y agoedited
.
knights15y ago
Dear Saradha, The write up you provided seems to be the rephrased version of "http://msdn.microsoft.com/en-us/library/ms973829.aspx"; without any references to the origianl writter/msdn(microsoft).Its misleading and doubt creating, for e.g, in MSDN version "Development takes a little longer because you must build separate components." is mentioned as disadvantage in N-Tier and you have listed this as one of the features. Even you if you disagree with the earlier version, i think you should mention the reference of article against which you are proposing new model. To make it different the diagrams you mentioned have taken away the originality of concept from the original article.Thank you.