Asp.NEt layers

smartsid

Member
Joined
Jan 26, 2003
Messages
11
Under an n-tier application, in which layer does asp.net exists?
Is it the presenation layer, business object layer, data layer?

Also can I pass a dataset from data layer to the presentation layer? Is it a good thing to do?

Where can I find information about the different layers?
 
ASP.NET is not layer. ASP.NET is meant to be a complete application.
in n-tier Application there is

DATA --> Application Logic ---> Presentation Layer
or
DATA --> Presentation Layer
depends upon your project type

Yes you can passdata sets from data layer to presentation layer.

Well for information about layers try MSDN site. and search for Distributed Applications.

[edit]makes post friendly[/edit]
 
Last edited by a moderator:
Defining the layers is completely up to you, smartsid. Youll find articles on MSDN that talk about general strategy.

Generally ASP.NET is the middle and sort-of the presentation tier. When using a browser, the presentation "tier" is really split into two parts. First theres the web server which sends data AND layout information to the client. Second theres the browser, which is ultimately the presentation layer since it will do all the displaying of information.

You can also have ASP.NET spew out nothing but data. It acts more like COM+ used to - exposing objects and data - only it uses webservices over HTTP instead of DCOM. In that respect, ASP.NET is strictly middle tier.

This assumes that youre using a database, which is your data tier. You can put the database on your web server but I wouldnt - very bad idea. Or maybe you dont have a database, but files or something else. You may not even have a data tier.

As for your last question, yes you can pass datasets to the presentation layer assuming your presentation layer is NOT a browser (more likely to be WinForms). If your presentation layer IS a browser and you know its IE, you can pass the DataSets XML to the browser as an XML data island and use it that way.

-nerseus
 
In my case, I use VB.NET for my data and business layer, and ASP.NET for presentation layer. I think this is the most common way for 3 tiers architecture.

I am quite interesting in this topic and we may further discuss about it.

Nerseus: can you share with us, what type of architecture (layer) you use most?
 
We basically use the same model as Duwamish which supports both WinForm and WebForm presentation tiers. We originally came up with our own ideas for the different tiers but trying to get everyone to the same understanding for these proved quite difficult. As a result we found out the easiest thing to do is to use the Duwamish (or Fitch) model and then when questions arise about what functionality to put in each tier we can just refer to that and when new developers come in we can just say spend a day studying the Duwamish architecture inside and out, then they can be almost instantly productive without the need for big architecture discussions.
 
I use the architecture our architects suggest. I have a hand it the decision, but they make all the tough decisions. Its definitely n-tier as our projects are usually quite large, spanning a dozen servers or more. With that many servers involved (SQL Server, File Server, Web server, web services only servers, Application servers, etc.) it requires a lot more knowledge than I want to spend time learning. From my point of view, I reccommend where the web servers and application servers "live" in the architecture but thats about all.

From that, I must deal with the other issues such as creating a development environment that we can use for developers, QA testers (2 levels), and demos. Its quite a bit to consider since you cant necessarily rely on "convential" means to read application settings, such as the registry. For example, if you have one development application server hosting multiple COM+ components (VB6) but you need to have them point to two different SQL Servers for two sets of developers, you cant really read the registry to get a connection string. Or, if you use trusted connections and set the components identity then app server must be on the same domain as the SQL Server, which isnt always the case.

Plus, our current architecture supports a customized version of MSs auto-download feature. We built our own version checking and dependency checker to auto-download assemblies as needed AND only if you have access (access being defined by Active Directory, which holds some application data and permissions).

If youre a smaller company or an individual then its best to use a simplified 3 tier architecture. For testing purposes, Id suggest 4 servers, if possible: SQL Server, Application Server (COM+ components or .NET components) and 2 Web Servers if you are going to be hosting ASP or ASP.NET pages. Why two? You want some experience with NOT relying on the session since session information isnt shared between web servers so youll have to come up with a custom solution, such as storing session information in SQL Server.

If youre a larger company or developing a solution for one, its good to have someone like Microsoft come in and reccommend the "proper" way to set up servers and development machines. Youd be surprised by how much you can learn from 2 or 3 official Microsoft staff helping you out for a week. Expensive, but well worth it :)

-nerseus
 
Back
Top