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.
Annie CalverteditedPosted Jul 17, 2012, 3:50 AMEdited Jul 17, 2012, 3:51 AM
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 SingheditedPosted Feb 3, 2011, 12:42 AMEdited Feb 3, 2011, 12:42 AM
.
knightsPosted Jan 13, 2011, 11:49 AM
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.