ASP.NET code behind pages and the 3-tier system.

Q_Ball

Hey all,

looking to get something cleared up. In a typical 3-tier system, are the code-behind pages (c#, vb) classed as the middle tier?

as in

HTML(.ASPX page) - Code-behind(.ASPX.cs, .ASPX.vb) - Database

Evil Phil

hmm, I would say they are in the UI/1st layer going on how I generally design things but I don't think that's going to answer your question.

Code behind pages contain code for the aspx pages in the application and as such are *coupled* to the web pages so they're part of the UI layer.

This doesn't mean you can't have middle/business logic layer code in them but that would be bad design imho.

Q_Ball

Evil Phil wrote:

hmm, I would say they are in the UI/1st layer going on how I generally design things but I don't think that's going to answer your question.

Code behind pages contain code for the aspx pages in the application and as such are *coupled* to the web pages so they're part of the UI layer.

agreed.

Evil Phil wrote:

This doesn't mean you can't have middle/business logic layer code in them but that would be bad design imho.

That'd be my opinion too, but when i was on one of microsofts mcp courses they included ADO logic in the code behind pages. I dismissed it as I put this down to it being used for demonstration purposes and that maybe i was thinking of it in JSP/EJB terms, and that IIS as a web server handles ASP pages and their code behinds different to say apache and JSP pages.

ChippingSodbury

I'd agree as well!!

The "code behind" pages are the code for the presentation layer. You can have as many layers as you like but industry norm is three. It's three for a reason: it makes the code most manageable and amenable to changes. Having said that, there's no reason why you couldn't have 4 tiers if it suits your particular application.

When you're designing your app, think of why you would make the three layers, don't just blindly follow "because it says it in a book"!!

The first layer should be the presentation layer: should contain all code to manage the presentation layer (code to fill dropdowns, manage events etc.)

The second layer should be the business logic layer: should contain all code to manage your business objects. Typically, business objects will have private members, private and public properties, private and public methods and functions. Things like NewDocument, EditDocument, DeleteDocument would be functions in a document object in a business layer of a document management system: These functions would then call corresponding functions in the data layer. The business layer can also hold things like validation code for ensuring all values filled (this could also be in presentation layer), other business rules you want to verify before certain operations are allowed.

The database layer should be the ONLY layer that communicates with the database. This should contain all of the SELECT, INSERT, UPDATE and DELETE statements for all of the system. The reasoning behind this concept is that if you change the database type e.g. from MySQL to SQL Server, you only have to change the code in one layer: your presentation layer and business layer should be completely unaffected.

Hope this helps.

Smoggy

"HTML(.ASPX page) - Code-behind(.ASPX.cs, .ASPX.vb) - Database"


What you have here is a traditional client / server model. The same as ASP calling the database.

Draupnir

Yes, but the style of coding which was prevalent with ASP calling the db etc. is exactly what .NET wants to get away from.

I believe it should be:

ASPX page - APSX.cs calls Business classes to perform actions. If the action requires DB access:

Business class calls DB layer.

Smoggy

The reason for keeping the UI / Business / Data sepearate are many , but some are , interface independance, as you can swap the UI with minimal recoding , the same is true for the data layer, using different database / data sources. Being massively more scalable. Reuseable etc etc