We are developing a
.NET web application that uses
WebApi. We have separate layers:
- UI (HTML, CSS, js etc.)
ApiController- receives input
DTOs from the UI and calls the appropriate endpoint in the Business Layer (for instance,
Business Layer- contains all business logic; doesn't save data into the DB directly, but calls the DAL (data access layer).
Data Access Layer(uses Entity Framework for CRUD or, in more complicated scenarios, performs some complicated queries and so on -- it does not have business logic).
- We use "Business Objects" (classes that EF operates with; these objects usually are transformed into database tables in our relational database).
- We use "View models" (used in Controllers and also in Business Logic).
- We use Automapper to map
View models. Mapping usually is done in our Business Layer.
- We also have dependency injection (all BLL and DLL classes have interfaces).
- We have additional Services like
Workflowetc. We do not have problems with these.
So, so far we have tried to separate all logical parts.
Here is definition of architectural problem I am faced with:
It is written much about overall architecture issues and how to separate layers. But the problem which I face with is that we have a lot of logic in our Business Layer. When we just started to develop this application, the code resulted in very large Business Layer classes with many
private methods. Then we started to create
Helpers. This helped us to clean our BusinessLayer a bit, but still, we have very large
Helpers and something like "
HelpersOfHelpersOfHelpers". Of course, we often name it differently, like "Importer" or "Calculations" or "Exporter", but still, often these are just Helpers with some weird names.
Can you give some clues how to structure Business Logic? These could be pattern names, some suggestions on additional reading or anything else.