What to put in Business Logic Layer?

Question

I have read lots of articles and they seem to vary from one author/developer to the next. In my situation, I am thinking about this setup for testing a project:

1. Presentation Layer via ASP.NET MVC

2. Service Layer (my plan is ASP.NET MVC Web API; this is on separate assembly)

3. Business Logic Layer

4. DAL using EF

Some articles said I should not put CRUD operations on BLL and BLL should only contain business logic. Also, some said BLL should not access DAL. But what if a business logic needs data stored in DB to calculate/work on logic? I guess my questions would be:

1. If BLL shouldn't access DAL, how about those business logic that needs data in DB for it to be able to perform the logic?

2. BLL are entities, right? Are they the same as POCO or would I still have POCO in DAL?

3. Also, is DBContext in BLL? Some say it should so I'm confused.

4. What about the no CRUD in BLL? Should I do that?

5. Repository interface is in DAL?

Any additional comments/suggestions/information on what my planned setup would be very welcome (even if it is not related to BLL).

Answer 1

I worked on a project some time ago.

Our project arquitecture ressembled to what you suggest.

We had an ASP.NET MVC site, which accessed a WEB API (in an external solution).

The WEB API also referenced an external solution entirely made up of static libraries, which contained the data layer (just entities) and the persistence layer.

We also had Data Transfer Objects (MSDN) for communication between the web service and the clients, and to decouple the entities entirely from external solutions.

We had the business logic in the WEB API project. We would create, manipulate and store the entities from within the WEB API HTTP methods.

But we didn't accessed the data and persistence layer directly, we had an intermediate layer, we called it entities manager. These managers would be injected on our WEB API controllers (We used Ninject for Dependency Injection) and would handle the creation of the entity, and also the persistence, so we'd decouple everything.

This approach worked very well for us, and we made a pretty well maintainable and scalable project.

I hope it may be of help for you, and of course, there probably exist better techniques.

PS:

We used an IRepository interface provided to us by the entites manager to persist the entities. This was our only access to the persistence layer. Inner logic, such as persistence strategies (like EF's DbContext, or File IO) would be internal to the persistence project.

---

This is an example of our bussiness logic in one of our WEB API HTTP methods:

// "repository" is an IRepository<Entity>
entityManager.Transaction( (repository) => {
     Entity ourEntity = repository.CreateNew();

     //Manipulate the entity somehow

     repository.Add(ourEntity);
});