Question

I want all my layers BLL ,DAL and UI to share classes (concrete or interfaces).

Is this really a bad practice?

I prefer not to return datatables from my DAL methods but instead to return objects that BLL can use directly.

I want to have a separate VS project with the classes that all layers should know about.

Example: I want to define a lot class that all layers should be aware of. UI should be able to receive lot classes in order to display or make possible for the user to submit a lot to be processed. Also DAL should be able to query the db with lot classes and return them. BLL on the other hand should get these lots and apply business rules onto them.

If this is completely wrong what are the alternatives?

Answer 1

I want all my layers BLL,DAL and UI to share classes (concrete or
interfaces).

It depends on what type of classes. If you need them all to access common domain entities, then sure.

The important part is what you allow those layers to do with those classes. Your client/UI layer shouldn’t be able to modify the domain entities (and persist them) without going through some centralized business logic. This means your DAL shouldn’t be accessible by your UI, although they can both share common entities, interfaces, etc…

A common approach is something like this:

UI -> BLL -> DAL -> Persistence storage (DB, file, etc…)

Each of those layers can access commmon classes. As long the UI can’t directly access the DAL, you should be okay. You have a couple of options for this:

• Make the BLL accessible through a service (WCF, etc…)
• Put the DAL and BLL in the same project and make the DAL internal so only the BLL can access it

You end up with something like:

UI -> Service -> BLL -> DAL -> Persistence storage (DB, file, etc…)

I would strongly recommend Patterns of Enterprise Application Architecture by Martin Fowler. It will provide you with a good foundation for layering your application.

I prefer not to return datatables from my DAL methods but instead to
return objects that BLL can use directly.

That’s a good idea. This is where the idea of ORM comes into play. The DAL will typically know how to talk to the DB, and the DAL will also know how to convert DB-specific structures into your domain model. Domain entities go into, and back out of, the DAL. Within the DAL, domain entities are converted to DB-specific structures when persisting data. And the reverse happens: when the BLL requests data, the DAL retrieves the data and converts it to domain enties before passing it back out.