C# Web Api-将工作流与BL分离

我的队友和我争论web api控制器应该包含哪些代码。我们都同意控制器不应持有业务逻辑，但我们不同意将工作流放置在何处，以及工作流是否应与业务逻辑完全分离

他们认为端点应该是这样的：

控制器代码：

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

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)
        }

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

流程代码：

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

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类位于解决方案中的业务逻辑项目下

我给他们看了这个答案： 但他们仍然说这段代码更具可读性

最让我不安的是，流类位于业务逻辑项目下，我认为这鼓励开发人员将业务逻辑放在流类中，并将BL与工作流结合起来。我不认为有理由创建这个只有一个公共方法并且在项目中只使用一次的类

它可以通过两种方式进行测试，但是当纯BL位于flow类内部时，测试纯BL要困难一些

工作流是否被视为业务逻辑？

---

谢谢你的回复

正如您在附件中所说，控制器应该是客户端和逻辑之间的中间层

将工作流与逻辑分离有一些优点，最重要的一个是防止它们之间的高度耦合，并使分别测试它们成为可能

---

在我看来，如果流不是非常复杂，并且没有任何逻辑，它可以位于控制器下，那么包含逻辑的复杂流是从控制器中提取流的唯一原因。

建议的“流”对象仍然通过使用

HttpResponseMessage

之类的东西耦合到应用程序类型（web应用程序）。因此，它仍然是web应用程序的一部分，而不是它自己独立的东西。我想真正的问题是。。。这种逻辑需要是它自己独立的东西吗？它会被其他web应用程序使用吗？它会被其他类型的应用程序使用吗？或者这仅仅是为了想要更多的运动部件而添加运动部件？这一切听起来都是基于观点的。关注底线。。。实际得到/失去的是什么？不知道返回

HttpResponseMessage

的内容如何被归类为业务逻辑。如果你要像这样创建

SomeFlow

，至少把它放在webapi项目中，而不是放在业务逻辑层。我认为违反单一责任原则比理解业务逻辑不应该位于webapi项目下更容易。我不介意这些类位于WebAPI项目内，但我不希望它们位于BLL项目下。我没有看到通过将流分离到不同的类获得任何好处，我们从未在所有其他项目中多次使用它们。