Web Api - 从 BL 中分离工作流 [关闭]答案

【问题标题】：Web Api - separating workflow from BL [closed]Web Api - 从 BL 中分离工作流 [关闭]
【发布时间】：2018-05-20 13:02:26
【问题描述】：

我和我的队友争论 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://stackoverflow.com/a/12694104/9062092 但他们仍然说这段代码更具可读性。

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

在两种方式上都可以测试，但是当纯 BL 位于流类中时，它会更难测试。

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

感谢您的回复！

【问题讨论】：

提议的“流”对象仍然通过使用HttpResponseMessage 之类的东西与应用程序类型（Web 应用程序）耦合。所以它仍然是网络应用程序的一部分，而不是它自己独立的东西。我想真正的问题是......这个逻辑需要是它自己的离散事物吗？它会被其他 Web 应用程序使用吗？它会被任何其他类型的应用程序使用吗？或者这只是为了想要更多的移动部件而添加移动部件？这一切听起来都非常基于意见。关注底线...实际获得/损失了什么？
看不到返回HttpResponseMessage 的东西如何归类为业务逻辑。如果你要这样创建SomeFlow，至少要放到web api项目中，而不是业务逻辑层。
我认为违反单一职责原则比理解业务逻辑不应该位于webapi项目下更容易。我不介意这些类位于 WebAPI 项目中，但我不希望它们位于 BLL 项目下。我没有看到将流分离到不同的类有什么好处，我们在所有其他项目中从未多次使用过它们。

标签： c# web-services asp.net-web-api model-view-controller

【解决方案1】：

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

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

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

【讨论】：