Three tier architecture

I have some questions about three tier architecture.

1. how to implement an application in three tier architecture correctly?
2. how to communicate between these tiers ?
3. Is data tier completely equals to DBMS? (how about in a case if we use stored procedures and how about in a case if we used a object relational mapping framework ?)

looking forward to hear your answers. Thanks.

PS: Please don't understand that I'm asking a general question. ok ? I'm asking how to design a large scale applic开发者_StackOverflow中文版ation correctly. What is the BEST way?. Not expecting looooong answers.

These are broad answers, I'll do my best to give you some pointers.

1. "Correctly" is a somewhat subjective term. Generally speaking, in my opinion the most important thing is to keep the layer in its own module (e.g., its own DLL), and have interfaces going in and out of the module. By using interfaces in each layer, you can separate the definition from the implementation, further decoupling the layers from each other. If there is a single entry point into the layer, and it is based on an interface, you can have several underlying implementations, as needed. In the other direction, if you use interfaces as callbacks, then the layer clients (i.e. the other layers) will only need to implement the interfaces in order to get a good flow between the layers.

2. That depends on how you implement the layers themselves. If you design the layers like I suggested above, you would simply use interfaces to go into the layer and out of it. Another solution might be to make it asynchronous, using event dispatchers - a layer would simply fire an event, and a different layer would listen to this event and act upon it. It all depends on the specific requirements of the project.

3. No, the data layer is the layer within the application that interacts with the DBMS. Using ORM is simply a method for implementing the data layer, while using stored procedures is a method for moving some of the logic from the application into the DBMS itself, for a variety of reasons.

I guess you'll receive several answers; you should take all of them into account, do some reading over the net, and experiment a bit until you find what you like.

1. The three tiers are Presentation, Business Logic and Data. Make sure that you don't mix the concerns. UI should not contain any business logic and so on.

2. Any tier should know only about the tier below it. For ex. UI should communicate only with Business Logic and should not know anything about data layer. To achieve this always code to interfaces instead of concrete implementations. Use Dependency Injection to keep modules loosely coupled.

3. This depends on how you choose to implement it. Start with YAGNI principal. Keep things as simple as possible to start with and use things like ORM only if you really need them.

This topic is too broad to properly answer this question in the depth required. That said:

1. A key item is to properly limit the dependencies between layers so that each layer only knows of the layer "below". e.g. the business layer does not know about the presentation layer.

2. 3-tier architecture makes no prescription on how the layers communicate between each other. Business (tier) functionality is frequently exposed as web services which are consumed by the presentation layer.

3. The data tier is not completely equal to the database. You will always need some code to interact with the data store (e.g. ORM). This code should be in its own module to minimize coupling.

This depends on many factors. I would look at using a repositiry pattern for your Data Access Layer (DAL). Ideally this would be used in conjunction with an object relational mapper (ORM) like entity framework 4, or nhibernate. I would then have a seperate domain layer that contains business rules and services. Your Domain layer would service requests between your UI and and You DAL. For your UI you have the option of web forms or an MVC approach. Both will still work within the three tier but you'll get much better seperation of concerns from MVC. This is good when you want to do some unit testing. Here are some good links regarding the above.

http://daveswersky.com/2010/05/26/entity-framework-4-then-and-now/

http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman

http://www.asp.net/mvc/tutorials/mvc-music-store-part-1

Three tier architecture is a concept not a step by step instructional. Keep it simple and isolated. If you are working with data storage and retrieval, put it in the data layer. When there is logic to be had, place it in the logic/middle layer. Themes/skins, views, widget placeholders go in the presentation layer.

Study others code. A good place to start would be monoRail.

Read lots of documentation the more you know what others are doing the better.

Above all, have some fun with it. If you feel overwhelmed or like things are getting complicated, step back and find out what's in the wrong place.

Best way to implement an application in 3 tier architecture is to use a framework of your language that use MVC. For PHP I recommend CodeIgniter http://codeigniter.com/

Usually what happens is the passing of objects, if you follow OOP, between the three levels. Well, mostly two. Control gets the request, asks the Model (DB) and gets an object in return, uses the properties and methods of that to display the View.

Follow some tutorials in Ci. You will get an idea of whats happening in MVC.

There are three layers in three tier architecture which are Presentation layer, Business logic layer and Data access layer. Apart from these three we can use a business object layer to implement property classes that can map our objects with the database or you can use entity framework.

Presentation layer : This is the top-most layer of the application where the user performs their activity. Let's take the example of any application where the user needs to fill up a form. This form is nothing but the Presentation Layer. In Windows applications Windows Forms are the Presentation Layer and in web applications the web form belongs to the Presentation Layer. Basically the user's input validation and rule processing is done in this layer.

Business layer : This is on top of the Presentation Layer. As the name suggests, most of the business operations are performed here. For example, after collecting form data we want to validate them with our custom business rule. Basically we define classes and business entities in this layer.

Data access layer : On top of the Business Logic Layer is the Data Access Layer. It contains methods that help the business layer to connect with the database and perform CRUD operations. Generally all database related code and stuff belongs to the Data Access Layer. Sometimes people use a platform-independent Data Access Layer to fetch data from various database vendors.

Further details - https://www.c-sharpcorner.com/UploadFile/dacca2/understand-3-tier-architecture-in-C-Sharp-net/