Fully utilizing the layers of an n-layered web application

First off, let me say that this article pretty much changed how I program, for the better. Until I read this article, I was a spaghetti programming master --- if there were awards for crappiest, least organized, and impossible to read programming, I would have been world champion. But that article taught me to utilize classes (mind-blowing, I know), rather than just copy/paste the same logic around to the necessary pages. With that in mind, I modeled my application (described below) on the examples found in that article. I highly recommend that article for anyone else who's looking to make the jump from newb coding via facerolling on the keyboard to newb coding with some thought behind it.

I've been simultaneously building upon and maintaining this web application for a year now, and I feel that while the layered approach has helped me to stay more organized, I'm not utilizing very much (if any) extra power from having layers.

In my web application Project, I have a folder I created called Classes. The structure looks like this:

/Classes
    /ClientManagement
         /DataAccess
              ClientDB.cs
         /Logic
              ClientManager.cs
         /Objects
              Client.cs

The above is extremely abbreviated (for example, ClientManagement actually has about 20 Objects, 20 Managers, and 20 DBs), and there are other base folders like EmployeeManagement, InventoryManagement, etc. Each "Management" base folder corresponds to a schema in the database, so that for example, in my SQL Server database, I have [myDatabase].[ClientManagement].[Clients].

Each class in the Objects folder looks something like:

```
public class Client
{
//fields
private int? _clientID = null;
private string _clientName = null;

//properties
public int? ClientID
{
get { return _clientID; }
set { _clientID = value; }
}

public int? ClientName
{
get { return _clientName; }
set { _clientName = va

Fist off, congratulations on your transformation. It's always nice to hear about people seeing the light!

Second I tend to agree with you. If the layer is doing nothing but passing calls to another layer, it is not needed. I would take it out. If, in the future you decide, or figure out what that layer contributes to the project as a whole, you can easily put it back in.

Another thing I'd be careful of is creating public static classes. They have their uses, but too many of them and you start moving from OOP back to procedural programming. What I'm talking about is the ClientDB class. I would rather see it as a class that is injected where it is needed, either manually or using a Inversion of Control (IOC) container.

For more on dependency injection and IOC, read this blog. Then you will become truly enlightened.

StackExchange Code Review Q#15864, answer score: 6