Drakoumel Drakoumel - 1 month ago 14
ASP.NET (C#) Question

Business Logic on ASPNet MVC outside of Model

I have been working with asp.net core web api for the past few days, I am familiar with MVC and SOC etc but I got confused a bit with the core mvc tutorials.
So in all the tutorials (to keep them simple) they put the business logic inside the Controller, but this is ofcourse not compliant to MVC.

In general I have created:


  • Model (to create the DB structure through EF)

  • Controller (to serve the endpoints and act)

  • Repositories (to provide the query logic to the DB)



Now I am bit confused with Services and also where am I supposed to put the business logic? I mean the Model is one place, but I dont want my controller to access the model directly but more like a Facade/Factory.
How do we achieve this in aspnet?

You can find my working repo at https://github.com/drakoumel/DatacircleAPI

I hope that after I can get a good explanation of this, to write it in the documentation of stackoverflow to help others.

Answer

There are so many approaches to this and there is not a single correct answer to your question.

Basically, the models you use in your views should not be the ones, that you persist in your database. Therefore, what you can do for example, is create a 'service' layer, so controllers operate on services, and services operate on repositories. This way you achieve a clear separation of concerns between each 'layer'.

First of all, keep persistance models and business logic out of controller. The only logic that belongs to a controller is application logic.

Secondly, introduce business logic layer (AKA. services layer), in which your business logic belongs. You can also create separate models in that layer, so your controllers do not operate on the models that represent your database entities, and you just apply mappings between models that services expose to your controllers and models that they pass to the repositories. Take those services as dependencies to your controllers. Your services will also take your repositories as their dependencies.

This way your controller has no idea what your business logic is - it only knows that it has to call some service which takes care of everything. Your service has no idea about where it's being used, he knows nothing of controllers, views or the way your data is presisted in the database - it just executes your business logic. And your repositories just persist your entity in storage of your choice, they only know their entity model and how to persist it. They haven no knowledge that there are services, controllers or views. The benefit which you get from is that when you decide to change your code, whether it's the business-validation logic of minimum allowed customer age or the mechanism or saving your entity, you are likely to do it in just one place in your code, place that is responsible for that specific thing.

Keep in mind that is the minimal separation of concerns between those components that you can do. Be aware that everything depends on your case and creating simple layers between presentatio, business logic and data persistance layers is not always the right or trivial thing to do, as it might sometimes be tricky not to leak your business logic into layers other than where they actually belong.