Implementing an API for a website’s business rules: is it an exaggeration? Or is it good practice?

Asked

Viewed 127 times

0

In some places that I worked with C# MVC I saw two ways to program the business model of a web system, being them: coding inside the Controller of the web application; creating a web API Rest and creating the business rule in the API, just calling this API inside the web application controller.

Just to be clear, an example:

An application that registers a client, in MVC there will be a View called 'Register.cshtml' with html code and create a registration form. When you click to register, the form data will be sent to the Controller Register.Cs, and that’s where the differences come in.

I can simply already register the client right there in the Controller or I can create a Rest Web API that does this, so in the Controller I would just call this API. This way, my web application would have basically the views, but no access to database or business rules, and those rules would all be in the API.

The question is: is it better to do so? Why? I think it can be an exaggeration and even harm performance, but I have heard that it is good practice, precisely because the business rule is in the API.

c# mvc asp.net-core
  • 1

    First, the business rule should not be on Controller. Second, the issue of the Webapi would be very useful if you want to make the features available to other customers who are not within your Solution or who are not .net. Here comes the advantage of the business rule not being implemanted on Controller and yes in an isolated layer, so you can expose and access it as your need

1 answer

1


The correct thing would be to have a second layer of "Services" that will have its business rules (never directly in the controller).

The use of the API makes sense for medium/large projects (facilitates maintenance), and for code reuse (for other systems).

Browser other questions tagged c# mvc asp.net-core

You are not signed in. Login or sign up in order to post.