| Author: UltimateRengan 25 Jul 2008 | Member Level: Diamond | Rating:  Points: 1 |
1.Presentation Layer
2.Business Logic layer
3.Data Access Layer
|
| Author: Ashok 25 Jul 2008 | Member Level: Gold | Rating: Points: 1 |
There are three layers....
1.Presentation Layer
2.Business Logic layer
3.Data Access Layer
3 Tier application
Quite often you hear developers speak about 3 tier (or n tier) applications. This is a technique to develop your application in several layers to keep different things nicely separated. The basic idea of a 3 tier application is to separate your data, business logics and the presentation.
In the data layer you have CRUD (Create, Update, Delete) methods for your tables (or other data source). You might add some minor business logics in combination with those tables (e.g. max, count, ...) and usually a singleton class is used to provide connection to the business layer.
In the business layer you have all the domain classes with their variables, properties and methods. The variables contain the status of your business entity and are hidden to the outer world by using data hiding (private, protected). Public properties provide the data of these variables to client applications while methods implement the business logics.
It's common used to have a Facade in front of your business classes to provide communication with the client application or presentation layer. A facade combines all the methods that can be used from outside in one single class and makes it easier for others to use the business layer since it's not needed to know how everything works behind the facade.
The third layer of a 3 tier application is the presentation layer. This can be any type of user interface, for ASP.NET is this a Web application.
|
| Author: Ashok 25 Jul 2008 | Member Level: Gold | Rating: Points: 1 |
ADO.NET object model
ADO.NET has both connected and disconnected classes to handle data. The connected classes are located in a .NET data provider and are used for communication with a database and can be placed in two groups. At one side you have all the classes to set up a Connection, to handle a Command and to read the returned data (DataReader).
On the other side you have a DataAdapter. This adapter implements all four sql commands (Select, Insert, Update and Delete). With setting the sql code for a select (on a single table), the other three commands are automatically generated. This DataAdapter is quite often used to supply large quantities of data to controls like GridView or connect disconnected classes to a data source.
The disconnected classes can retrieve a DataSet from the connected classes or from an xml file. The DataTable implements a DataRowCollection, DataColumnCollection and a ConstrainCollection and acts like a database table (but then disconnected from the database).
For details refer :
http://www.beansoftware.com/ASP.NET-Tutorials/ADO.NET-DAL.aspx
|
| Author: Ashok 25 Jul 2008 | Member Level: Gold | Rating: Points: 1 |
The three layers are:
* Presentation Layer
* Business Logic Layer
* Data Access Layer
In short, the process works like this:
* User requests for some application data.
* The data access layer retrieves the data and is forwarded to the presentation layer via business logic layer. Sometimes data access layer gives this data directly to presentation layer.
* Presentation layer receives the data to be displayed via business logic layer.
* The user changes the data and initiates the appropriate action (such as insert, or update).
* The business logic layer validates the data submitted by the user.
* If the data is valid it is handed over to data access layer for updating into the database.
|
| Author: Ashok 25 Jul 2008 | Member Level: Gold | Rating: Points: 1 |
Presentation layer options
There are two main options for creating presentation layers in .NET. They are - Windows Forms or ASP.NET Web Forms.
Using windows forms you can create traditional forms based desktop applications. Windows forms applications can offer rich user interface elements and response times to the user. However, they suffer from the drawback that they need to be installed on each and every machine. Though they can be used in "smart client" mode they are more or less the same as traditional VB forms.
The most appealing option to develop presentation layer is ASP.NET web forms. Traditionally web pages suffered from the drawback of limited user interface elements. ASP.NET web server controls bridge the gap to a great extent. Controls such as DataGrid, DataList and Calendar provide rich UI in very few lines of code.
Above presentation layer options can be coded in variety of languages such as C# or VB.NET. Here, again support for multiple development languages comes handy. You can use your choice of language to develop the UI.
Business logic layer options
Business logic layer primarily consists of components that perform the task of business validation, business workflow and other similar things.
.NET components form this layer. In case you have invested a lot in COM components then you can also use them in .NET via interop. However, this will degrade the performance.
ASP.NET Web Service can also serve as business logic layer. However, they should not be used as replacement to components in all the situations. They should be used only if the business validation happens at some "external" place than your network.
The components you develop need not always reside on the same machine. Using .NET Remoting you can create distribute them on multiple physical machines.
Data access layer options
This layer deals with data manipulation actions such as inserts, updates, deletes and selects. The data mentioned above can reside in RDBMS or XML files or even flat files. You should design data access layer in such a way that other layers need not have any knowledge about underlying data store.
ADO.NET is the data access technology under .NET. Though ADO.NET allows connected data access via DataReader classes more focus is on disconnected data access. DataSet plays a key in this mode. In some rare cases you can also use ADO for data access but it's use should have valid reasons. Do not use ADO just because you like Recordset!
Again .NET components form this layer. As stated earlier you may also use classic COM components.
Web services can also form data access layer. This is especially true if your database do not have a data provider. In such cases you can write some custom code to connect with the data and populate DataSet with it and then return DataSet to the caller.
In addition to ADO.NET you can also make use of built-in RDBMS capabilities such as stored procedures and functions.
|
| Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
There are three layers....
1.Presentation Layer
2.Business Logic layer
3.Data Access Layer
3 Tier application
Quite often you hear developers speak about 3 tier (or n tier) applications. This is a technique to develop your application in several layers to keep different things nicely separated. The basic idea of a 3 tier application is to separate your data, business logics and the presentation.
In the data layer you have CRUD (Create, Update, Delete) methods for your tables (or other data source). You might add some minor business logics in combination with those tables (e.g. max, count, ...) and usually a singleton class is used to provide connection to the business layer.
In the business layer you have all the domain classes with their variables, properties and methods. The variables contain the status of your business entity and are hidden to the outer world by using data hiding (private, protected). Public properties provide the data of these variables to client applications while methods implement the business logics.
It's common used to have a Facade in front of your business classes to provide communication with the client application or presentation layer. A facade combines all the methods that can be used from outside in one single class and makes it easier for others to use the business layer since it's not needed to know how everything works behind the facade.
The third layer of a 3 tier application is the presentation layer. This can be any type of user interface, for ASP.NET is this a Web application.
|
| Author: chandramohan 01 Aug 2008 | Member Level: Gold | Rating: Points: 1 |
he challenge of bringing data from efficient storage engines such as SQL Server into object-oriented programming models is hardly a new one. Most developers address this challenge by writing complex data access code to move data between their applications and the database. However, writing such code requires an understanding of the database, so that you can access data either from the raw tables, from views, or from stored procedures.
More often than not, databases are managed by DBAs whose job it is to ensure that the database is available, powerful, efficient, and secure. The means of accomplishing this generally take the data further out of the scope of your own concepts of how your data should be structured in your applications. It requires a solid knowledge of the database schema, table definitions, and stored procedures along with their parameters and results, views, keys, and more, so that you can create your data access code.
Entity-relationship modeling, introduced in the 1970s by Peter Chen, goes a long way toward solving this problem. Using entity-relationship modeling, programmers create a conceptual model of the data and write their data access code against that model, while an additional layer provides a bridge between the entity-relationship model and the actual data store. Most modeling, to date, gets done on a whiteboard.
With the ADO.NET Entity Framework, Microsoft has made entity-relationship modeling executable. They achieved this using a combination of XML schema files, behind the scenes code generation (creating .NET objects), and the ADO.NET Entity Framework APIs. The schema files define a conceptual layer to expose the data store's (e.g., a SQL Server database) schema, and to create a map between that and your application-level objects. The ADO.NET Entity Framework allows you to write your programs against classes that are generated from this conceptual layer. The Framework then handles all the required translation as you extract data from the database and send it back in.
Figure 1: How the different layers of the Entity Data Model fit into your application.
This article provides an explanation of the basic concepts of ADO.NET Entity Framework, gives you an opportunity to get your hands dirty with code, and provides a glimpse into the possibilities that ADO.NET Entity Framework opens up for developers.
Figure 1 shows the Entity Data Model's (EDM's) layers, how they relate to one another, and where the model fits into your application.
From DAL to a Foundation
The ADO.NET Entity Framework has a number of layers of abstraction. In its simplest form, you can use it as a data access layer complete with the easy-to-use wizards and drag-and-drop controls. In its more complex form, the ADO.NET Entity Framework is truly a foundation for the future of data access in Microsoft's data platform. A great example of this is to look at some of the projects that Microsoft is currently building based on the ADO.NET Entity Framework that were first presented at MIX07. One is currently codenamed "Astoria" and provides data through a specialized Web service. The service uses the Entity Data Model (EDM) to serve up a conceptual model of the data. Another project, code-named Jasper, uses the ADO.NET Entity Framework to build dynamic data layers with absolutely minimal effort on the end of the developer. By dynamic, this means that you build the data layer on the fly when you run the application, and there is a lot of dynamic data binding, etc. Check the Resources sidebar for links to more on these projects.
The point is that while the ADO.NET Entity Framework makes available APIs that developers can work with directly (the focus of this article), these APIs will also become building blocks for future development tools that Microsoft will provide down the road.
You can implement the ADO.NET Entity Framework in a range of scenarios, from using a default model with drag-and-drop data binding to constructing complex models to building services on top of the framework that you can use in a variety of ways.
In the rest of this article, you will see the simplest form of using the ADO.NET Entity Framework directly: drag-and-drop data binding against the default model. While this is a great entry point to understanding the ADO.NET Entity Framework, keep in mind that there are many exposed layers for developers to work with. You can access the model directly using Entity SQL or through the higher-level Object Services API. The conceptual model is highly customizable, allowing you to do things such as inheritance, or structure schemas that look very different than the data store upon which they depend.
|