How do you do it? Folders? class libraries (.DLL) for the Business Logic? class objects? Data Sets for the Data Access Layer? HELP If someone can show me a basic folder/organization structure for the project ifself it would really help! Thanx
Folders can help, but they aren't necessary to divide your design into it's logical layers. Usually classes and interfaces (if you want to be able to replace sections of your code) are sufficient.
An example: I have a website that has members that log in. They can access the site, change personal information, etc (all the usual website things).
This can break up into three easy layers: UI (the web pages), the business logic (actions available to the user at the web page) and data access (database access for logins and anything else).
Each layer gets one of more classes, depending on how logical it is to combine functions. I'll go through Logging in as an example of how this could be handled.
UI Layer
User accesses the website and is presented with a login page that takes a username and password (could be more, like a security question, domain, etc.).
The user fills these in and clicks "submit." This calls a function from the class holding the business logic. We'll say it's
- WhateverClass.Authenticate(string userName, string password)
The Business Logic layer
In
- Authenticate(string userName, string password)
several things should happen based on the rules specific to the business. This code needs to see if the login is expired, and the user needs to change passwords. This code checks to see if the password is correct, if the user exists, etc. BUT it does this without ever directly touching the database. Instead, it passes it's needs to...
The Data Access Layer
This code is passed information, and returns information. Little to no changing of data occurs here (that usually happens at the BL layer). There can be legitimate reasons for manipulating data at this layer, but it's usually considered to be bending the rules. To go along with the logging in example, a method in this code could be to retrieve the stored password and salt (if hashed or encrypted) based on username. This method looks in the database and hands the result back up to the logic layer. It doesn't look at the data, it doesn't check to see if the input password is correct, it doesn't care. The logic layer asked it for information, and it handed it back. That's all this layer does (well, and it's handed data and it writes it to the DB too).
It's a fairly simplistic example, but hopefully it shows how you can logically break up your program into the n-tier design style. It all basically boils down into the following rules:
1) Your user interface shouldn't make decisions, it should be told what the decision is, and react accordingly (it's told the user logged in, or didn't log in).
2) The business logic layer shouldn't know what your UI is doing with the information it provides (all it know is that the UI wanted to know if the user logged in or not). The business logic layer also shouldn't know how the data acess layer does anything. It could be a file, it could be a database, it could be my Aunt Mildred writing on a notepad for all it knows or cares.
3) The data access layer doesn't think. It reads, writes and erases. Someone asks it for a user, it passes it up. Someone asks it to save something, it writes it down. That's what it does. It's told to erase something. Yes, sir. Right away sir.
3
