0

This question already has an answer here:

Previously while working on database in asp.net I was using stored procedure with no tier architecture. So I was including connection string, crud query etc in every button click event.

Then I was told to use three tier architecture. I googled some way and found not so convincing answers. Help me find a proper one, the standard one.

marked as duplicate by gnat, Kilian Foth, JeffO, user53019, user40980 Oct 22 '14 at 15:51

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    -1 You googled .net three tier architecture and got nothing? I found 138,000 results. Many were tutorials on how to do it. – JeffO Oct 22 '14 at 12:03
  • 1
    You'd receive a better answer if you provided a bit more details on your app. Even though 3-tier often is the preferred way, it doesn't mean you have to do it this way. Especially if it's a very simple application not meant to grow in the upcoming years. – Crono Oct 22 '14 at 12:51
0

Whoever told you to use a three tier architecture clearly has some misunderstanding about the term and passed that misunderstanding to you. Tiers describe a physical separation between the parts of a system, layers describe a logical separation. What you're after is a layered architecture, you're already using a two tier one.

A typical three tier application is made up of a presentation tier (web, mobile or desktop applications), a business logic tier and a database/storage tier (SQL Server, MySQL, NOSQL). This is valid for applications that expose their logic to multiple clients through the means of a public API. The StackExchange network can be seen as a multitier architecture.

A multilayer application will be structured, conceptually, the same way as a multitier one, with the important difference that some of the layers (presentation, business logic, data access) can reside within the same physical boundary (tier), such as an assembly or an ASP.NET WebForms application.

The main problem you have in your application is that you don't have a clear separation between the data access layer, the business logic layer (which can be omitted if you're merely presenting some data from a database) and the presentation layer, hence the suggestion you received. Your presentation layer should be oblivious to the persistence layer. You are supposed to abstract the data access part of the code behind a class or an interface. This would give you the logical separation between presentation (the webpage) and data access (the class/interface).

Another problem that you may have is that inside the stored procedure you may be performing some business rules which would normally reside within the business logic layer. The opinions on this are divided and the decision on where to place these rules depends on multiple factors.

Not the answer you're looking for? Browse other questions tagged or ask your own question.