Asp.NEt layers

Defining the layers is completely up to you, smartsid. You'll 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 there's the web server which sends data AND layout information to the client. Second there's 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 you're using a database, which is your data tier. You can put the database on your web server but I wouldn't - very bad idea. Or maybe you don't 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 it's IE, you can pass the DataSet's XML to the browser as an XML data island and use it that way.

 

-nerseus

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. It's 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 that's 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. It's quite a bit to consider since you can't 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 can't really read the registry to get a connection string. Or, if you use trusted connections and set the component's identity then app server must be on the same domain as the SQL Server, which isn't always the case.

 

Plus, our current architecture supports a customized version of MS's 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 you're a smaller company or an individual then it's best to use a simplified 3 tier architecture. For testing purposes, I'd 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 isn't shared between web servers so you'll have to come up with a custom solution, such as storing session information in SQL Server.

 

If you're a larger company or developing a solution for one, it's good to have someone like Microsoft come in and reccommend the "proper" way to set up servers and development machines. You'd 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