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!
HttpResponseMessage
. So it's still part of the web application and not its own discrete thing. I guess the real question is... does this logic need to be its own discrete thing? Will it be used by other web applications? Will it be used by any other types of applications? Or is this just adding moving parts just for the sake of wanting more moving parts? This all sounds very opinion-based. Focus on the bottom line... What is actually gained/lost?HttpResponseMessage
can be categorized as business logic. If you are going to createSomeFlow
like this, at least put it in web api project, not in business logic layer.