Web Api - separating workflow from BL [closed]

Question

My teammates and I argued about what code the web api controller should hold. We all agree that the controller should not hold business logic but we don't agree on where to place the workflow and if the workflow should be entirely separated from the business logic.

They think that the endpoint should look something like this:

Controller code:

public Response EndPoint(...)
{
    var flow = new SomeFlow();
    var response = flow.RunFlow(...);
    return response;
}

Flow code:

public class SomeFlow
{
    public HttpResponseMessage Activate(....)
    {
        var service = new Service();
        var entities = someService.GetEntities();
        if(entities == null) return new HttpResponseMessage(HttpStatusCode.NotFound);

        foreach(var entity in entities)
        {
            BusinessLogicClass/Model.DoSomething(entity)
        }

        .....
        .....
    }    
}

SomeFlow.cs class is located under the Business logic project in the solution.

I've showed them this stackoverflow answer: https://stackoverflow.com/a/12694104/9062092 but they are still saying this code is more readable.

The thing that disturbes me the most is that the flows classes are located under the business logic project and I think it encourages developers to put business logic inside the flow class and couples the BL with the workflow. I don't see a reason to create this class that has only one public method and will only be used once inside the project.

It is testable on both ways but a bit harder to test pure BL when it is located inside the flow class.

Does the workflow considered as business logic?

Thanks for the replies!

Answer 1

As said in the post you attached,the controller should be a middle tier between the client and the logic.

There are some advantages for separating the workflow from the logic, the most important one is preventing high coupling between them, and making it possible to test each of them separately.

In my opinion, if the flow is not very complex and without any logic it can sit under the controller, a complex flow that contains logic is the only reason to extract the flow from the controller.