ASP.net application architecture and design questions

[John_Cambridge]

I often read about a 3-tier architecture consisting of a presentation layer,
business logic layer and a data access layer. I'm somewhat confused by the
BLL. Should the BLL be separate from the web application? (for example,
should I be able to take the BLL and DAL out of the ASP.net project and put
it into a WinForms project without any changes?)

For example, if I had a simple project where I had a class User (in the
BLL), as I understand it, I'd probably also have a class UserAdapter (in the
DAL). I assume the User class shouldn't reference any ASP.net objects? I'd
use the UserAdapter to load data from the database into a User object.
..aspx.cs files would contain the code for the presentation layer that would
utilize the User class.

In the above situation, my problem is, where do I put classes that reference
ASP.net objects? For example, what if I wanted to create a method getUser()
that checks the session to see if an existing User object exists for the
session, if not, it creates a new one. Where would this method go? To me
it seems like more a 4-tier architecture:

1. Data Access Layer
2. Business Logic Layer (contains no ASP.net specific code)
3. Classes & methods that contain ASP.net specific code??? (is this
considered part of the presentation layer?)
4. Presentation Layer

Also, what is the standard folder layout in the project for this type of
architecture? What folders would I put the code for each of the layers in?
How do I separate layers #2 and #3 from each other?

I've read many articles on this, but I'm still having problems understanding
where #3 (as stated above) should go. I've tried looking for sample
projects that implement this n-tier architecture, but all the ones I find
are either too basic (for simplicity reasons, they don't separate stuff
enough) or they're too complex (difficult to look through to understand the
entire application architecture). Much thanks to anyone who could help
explain this to me and also if you know of a good sample project that might
illustrate something like this. Thanks!

 

[sloan]

That's kinda what you're after.

The way I teach my junior developers on "how/what" to push down, my rule is

"If we wrote a winforms application tomorrow, what code would you have to
duplicate if you left the code in the presentation layer? If so, that's a
candidate for pushing "down" to the business layer".

Here is a downloadable example for you:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

Also, find the 1.1 version of that same article

http://sholliday.spaces.live.com/feed.rss

and read the 1.1 version AND find the "bird's eye" view MS article I
reference. Bookmark that article, and read it a few times through.

 

[iduditz]

It can be quite confusing with so many tutorials out there that make
different claims as to how layers communicate with each other, and with your
asp.net application

My general rule of thumb is that logical layers do not need to be physically
separated unless its really necessary (passing info between physical layers
is gonna take longer and will be prone to more errors).

As far as what should be visible within the asp.net code behind, I typically
use a service layer that the code-behind can use to interface with the BLL.
The service layer does not pass the actual business objects back to the
asp.net code behind, but rather, "dummied down" objects that represent only
the info necessary for the UI to do its thing. When I must store things in
session state (watchout memory!), i do not store the sometimes bloated
business objects, but these serialized simple objects.

Folder structure for my tiers:

Data - DAL-related code: data helper classes, Data provider interfaces and
classes
Business - business (domain) objects
Service - service-related code, such as repository service classes that may
take a Data provider interface type when passing on instructions to the DAL


Hope you find this info useful,
Ben

 

[John_Cambridge]

Thanks guys! The info is greatly appreciated!