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

我向他们展示了这个stackoverflow答案： https://stackoverflow.com/a/12694104/9062092 但他们仍然说这段代码更具可读性。

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

它在两种方式上都是可测试的，但当它位于流类内时，测试纯BL有点难度。

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

感谢您的回复！

Answer 1

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

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

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

Web Api - 将工作流与BL分离

1 个答案: