Presently I am working using single tier architecture. Now I am wanting to learn how to write code using 3 tier architecture. Please can you provide me with a simple example?
相关问题
- Carriage Return (ASCII chr 13) is missing from tex
- How to store image outside of the website's ro
- 'System.Threading.ThreadAbortException' in
- Request.PathInfo issues and XSS attacks
- How to dynamically load partial view Via jquery aj
相关文章
- asp.net HiddenField控件扩展问题
- asp.net HiddenField控件扩展问题
- Asp.Net网站无法写入错误日志,测试站点可以,正是站点不行
- asp.net mvc 重定向到vue hash字符串丢失
- FormsAuthenticationTicket expires too soon
- “Dynamic operations can only be performed in homog
- What is the best way to create a lock from a web a
- Add to htmlAttributes for custom ActionLink helper
A good tutorial, with complete source control download of a well written tiered application would be here:
http://nerddinnerbook.s3.amazonaws.com/Intro.htm
This isn't a tutorial about tiered architecture, but it's a well written app and gives some insight into why you might consider this architecture.
Additionally, as has only been briefly touched on above, this is about keeping your logic/storage/presentation code separate, so if you have to change one of them (e.g change from asp.net front end to a desktop application), it's not so hard to do.
By "tier" do you mean a "layer" in your software stack? The word "tier" is better used to describe the physical components of your system. If you are using ASP.NET, you probably already have a "3 tiered" system -
But you are possibly putting all of your code into a single software "layer" - specifically, the code behind file of your aspx pages. You want to move from a single layer to a 3 layer approach. The classic "3 layer" software architecture consists of the following -
Presentation Layer
Business Logic Layer (BLL)
Data Access Layer (DAL)
alt text http://weblogs.asp.net/blogs/fredriknormen/WindowsLiveWriter/UsingWebServicesina3tierarchitecture_134F6/3tier_2.jpg
For a typical ASP.NET app, you might apply this as follows. First, you create a LINQ2SQL file (.dbml) containing the objects for your database access. This is your Data Access Layer (DAL).
Next you might create a DLL to contain your Business Logic Layer (BLL). This layer will access the database via the DAL, manipulate it as required, and then expose it via a simple interface. For example, if your application displays a client list, your BLL might have a public function called GetClientList() which returned a list of clients.
Finally you would set up your code behind files to instantiate the BLL and wire it up to the interface components. This is your Presentation Layer. For example, it might take the data returned from your GetClientList() function and bind it to a data grid on the web form. The idea is to have the presentation layer as thin as possible.
This seems a little long-winded to describe, but it's pretty straight-forward once you have done it a couple of times. You will find that separating out your application like this will make it much easier to maintain, as the separation of concerns leads to cleaner code. You will also find it much easier to upgrade or even replace your presentation layer, as it contains very little smarts. Finally, you will get to a point where you have a number of very useful BLL libraries that you can easily consume in new applications, greatly improving productivity.
Presentation layer: put everything that is related to user interface. (What the user sees)
Business layer: everything that is related to the logic of the application (How is the information coming from presentation layer treated)
Data layer: provide an abstraction of the underlying data source(s) (Where and how the information coming from/going to business layer is stored)
Each layer should know as less as possible about the other and it should be a top down approach:
Simple example:
Website:
Three-tier (layer) is a client-server architecture in which the user interface, business process (business rules) and data storage and data access are developed and maintained as independent modules or most often on separate platforms.
Basically, there are 3 layers:
What is the need for dividing the code in 3-tiers? Separation of the user interface from business logic and database access has many advantages. Some of the advantages are as follows:
A 3-tier architecture usually has the following components:
So to answer your question on how to write code for a 3-tier architecture, you develop an ASP.NET application that communicates with a data storage.
This is what I have in my project. More than just a traditional 3-tier architecture.
1.) Application.Infrastructure
2.) Application.DataModel
3.) Application.DataAccess
4.) Application.DomainObjects
5.) Application.BusinessLayer
6.) Application.WebClient or Application.WindowsClient
Application.BusinessObjects are used across the application and they travel across all layers whenever neeeded [except Application.DataModel and Application.Infrastructure]
All my queries are defined only Application.DataModel.
Application.DataAccess returns or takes Business objects as part of any data-access operation. Business objects are created with the help of reflection attributes. Each business object is marked with an attribute mapping to target table in database and properties within the business object are marked with attributes mapping to target coloumn in respective data-base table.
My validation framework lets me validate each field with the help of designated ValidationAttribute.
My framrwork heavily uses Attributes to automate most of the tedious tasks like mapping and validation. I can also new feature as new aspect in the framework.
A sample business object would look like this in my application.
User.cs
BookCollection.cs