Web Api - 将工作流与业务逻辑分离

Question

我的团队和我就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)
        }

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

SomeFlow.cs类位于解决方案中的业务逻辑项目下。

我向他们展示了这个stackoverflow答案: https://dev59.com/fWcs5IYBdhLWcg3woFft#12694104，但他们仍然认为这段代码更易读。

最让我不安的是，流程类都位于业务逻辑项目下，这样会鼓励开发人员将业务逻辑放入流程类中，并将BL与工作流紧密耦合。我不认为有必要创建只有一个公共方法且仅在项目中使用一次的这种类。

无论以何种方式进行测试都可以，但当BL位于流程类中时，纯BL的测试可能会稍微困难一些。

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

感谢回复！

- Nir Petrushcka

---

提议中的“流程”对象仍然通过使用HttpResponseMessage等内容与应用程序类型（Web应用程序）耦合在一起。因此，它仍然是Web应用程序的一部分，而不是自己独立的东西。我想真正的问题是...这个逻辑需要成为自己独立的东西吗？它将被其他Web应用程序使用吗？它将被任何其他类型的应用程序使用吗？还是只是为了想要更多的移动部件而增加移动部件？这听起来都是基于观点的。关注底线...实际上获得/失去了什么？ - David

看不出返回 HttpResponseMessage 的东西怎么能归类为业务逻辑。如果你要创建像这样的 SomeFlow，至少将其放在 Web API 项目中，而不是业务逻辑层。 - Evk

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

Answer 1

如你所附带的帖子所述，控制器应该是客户端和逻辑之间的中间层。

将工作流程与逻辑分离有一些优点，最重要的是防止它们之间高度耦合，并使得可以单独测试每个部分。

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

- Sagi Levi