DAL vs BLL – Choosing the Right Return Types

1. Yes. And also assemblies.
2. I'd separate by layers, then components.
3. Yes. There are different approaches to this, but I'd have an IDatabaseService (abstracting the various manners in which the database is called -- this can almost be a direct mapping of the ExecuteScalar/ExecuteNonQuery/ExecuteReader), and then various data access classes that partition by type of data. For example, you could have a UserDataAccess class that would have simple CRUD methods that create/modify/delete User objects. Another approach would be to have a User object that has the CRUD built right in.

4. No. That makes it much harder to unit test. You should use dependency injection to pass in dependencies to the constructor of each data access class (such as an IDatabaseService). You would then pass the data access objects into the business objects, like this:

   BusinessObject businessObject = new BusinessObject(new DataAccessObject(new DatabaseService())); businessObject.PerformOperation();

Each business object may need multiple data access objects. Your GUI code would also use one or more business objects. Some business objects may not need any data access objects but should never use the IDatabaseService directly.

Your DAL should return your data objects

Ideally your DAL should be a "black box" object, that your application code can use to ask for a data object or manipulate existing data objects. Sometimes there is another layer put between the DAL and the application code called the Repository, which further separates the two layers, although this is not always needed.

In addition, you usually do not want your business objects being able to create themselves. This can cause security holes where someone can use your library, and create a new instance of your object by calling .Load(someId) on it, and it merges together two layers that should be completely separate.

I also don't recommend providing a.Load(DataSet ds) method because if the data set definition changes, you'll have to hunt down the data objects which use that data set and change them. It's easier to keep all your data access code in one place, so if you change the data access query, you should only have to change your DAL layer.