What to put in Business Logic Layer? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

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);
});

Answer 2

The data will take different forms, for example in the data storage DS (SQL Server for example) they are on relational tables, in the data access layer DAL they are in the Data Model (object model) like Entity Framework EF, in the presentation layer PL they would be in View Model, and on the HTML page or desktop form they will live inside a UI component.

At a single point when a layer calls another layer they have to have a communication channel and a data container that would change the data from one form to another.

Whenever a DAL asks for some data from DS it should be changed from table form to a object model form, so the DAL does not care about the table form. When you send the data back from the DAL to the PL it should be changed to be in a View Model form and again the PL does not care about the object model form, and so on.

You might ask about the BLL layer, I guess this layer most of the time is just a delegate in the middle when there is no logic in the middle, so for some performance matters the PL would access the DAL directly.

I hope this would answer your questions.

EDIT

For the BLL you consider as the mind of the system, the PL is just showing what it receives, and DAL just returned what is asked for to return by acquiring the right DS entities. So the CRUD would be in the DAL.

For Example you need to search for a list of employees, the BLL here is just a delegate layer where it delegates the PL call to the DAL and return back the results. But in case of adding a new employee, the BLL would have an interface with function like AddNewEmoloyee which will do some business logic functions like for example making sure that the salary is according to the employee level range, and then it will call the needed CRUD actions in the DAL.