Hi Rohit,

The ideal N-Tier is that DAL ( Data Access Layer ) , as it's commonly use, speaks to BLL ( Business Logic Layer ), and BLL speaks right to Presentation layer, no communication is allowed, ideally, between DAL and UI or in other words no jumps are preferred, you can do validation at BLL if you require some data from the DAL, for example you can put validation into the BLL in case you need to check whether one UserID is existing in DB or not, or you can opt for doing it in UI to check length of input text or other stuff like this.

Regards,

Rohit,

What you are describing above has very little to do with ASP.NET 2.0. You in fact are describing the fundamental design and usage goals for a layered architecture (could be ASP.NET 1.0, 1.1, 2.0, WinForms, Java, etc...). Great news, you're in the right forum that's for sure :)

One of your questions above seems to be about strict vs. relaxed layering. In the case of strict layering you will not be able to "skip" one of the layers in order to streamline execution. You may find patterns like the 'Fast Lane Reader' that recommend this approach so don't get too tied up into this decision. At the end of the day you are looking for loose coupling (which you are referencing with the 'blackbox' concept) and high cohesion (a type should do one and only one thing). If you start to relax your layering you are bound to start implementing over-flexibility in one of your layers (probably the UI).

Like any other decisions in architecture there is a set of trade-offs you'll need to evaluate. Often skipping layers for expedient data retrieval provides for a performance benefit but the diverging style of the code can add complexity making it hard to maintain.

I also want to caution you not to use the term 'Layer' and 'Tier' interchangeably. When I look at my layered architecture I am probably looking at something like this:

User Interface > Service Facade > Workflow > Business Entity > Data Access

If I'm talking about Tiers I'm realistically looking at only a couple of options:

1. UI Tier > Business Tier > Data Tier

2. UI Tier (w/ Layered Business Components) > Data Tier

When you're thinking about tiers think about physically hosted code on physically different process spaces (often crossing network boundaries).

Also, when you start to ask questions like "does this depend on that" just think about whether or not your code can work without it. Can your code function without the data tier ... not likely. For this reason a layered model like this often has dependencies throughout the stack as nothing can really operate in autonomy. Now if you want to start to talk about loose coupling and SOA ... well that's a different story.

Hope this helps.

The problem that you have is that your level of abstraction is too high.

If you were to employ the MVP pattern (a variant of the well known MVC), then you could cleanly separate UI concerns (the ASP.Net pages) from presentation logic (the P in MVP stands for "presenter"). The (V)iew in this case would be the asp.net page. It would implement an interface, say ICustomerForm, which would expose a "save requested" event. The presenter would handle that event by retrieving the customer data from the view and passing it to the business logic to be saved.

While this pattern is fairly easy to implement in WinForms, in asp.net you need some more tricks. On the other hand, you could use a dependency injection framework to handle these tricks for you. http://www.SpringFramework.net is what I use.

Hope that helps.