三层架构业务逻辑答案

【问题标题】：3-tier Architecture business logic三层架构业务逻辑
【发布时间】：2019-09-12 18:58:48
【问题描述】：

我有一个关于服务层的问题 - 现在我的控制器与服务层交互，我在其中使用 EF 上下文，但有时服务方法中的业务逻辑可能非常庞大，大约 1000 行。例如：

class OrderService {

   public async Task UpdateOrder(OrderDto dto) {

      if(dto.Products.Count > 3)
      {
         **change order status that can take 300 lines**
      } 

   }
}

我在哪里可以保留我在 if 语句中使用的逻辑？通常我只是在该服务中创建私有方法，但我不确定这是一个好方法。也许为此创建特定的类或类似的东西？

谢谢。

【问题讨论】：

可以为业务逻辑添加另一层吗？服务层可以与业务逻辑对话，业务逻辑可以与数据层对话。
@imAbhi 谢谢你的建议，我已经试着找到证据证明我可以像你说的那样做，但我做不到。那怎么用呢，不是我所有的方法都需要500行业务逻辑，还是不需要任何具体逻辑也总是通过业务服务调用？
也许考虑添加一个 OrderServiceHelper。你的班级和方法应该遵守单一职责原则en.wikipedia.org/wiki/Single_responsibility_principle 这确保你的班级只做一件事，并且把那件事做好。然后，更新顺序方法可以调用此类以在状态更改时执行逻辑。

标签： asp.net asp.net-mvc asp.net-core asp.net-web-api

【解决方案1】：

这个问题可以更多地从开发者的个人角度出发。这是我用来组织代码的一些技术。只需尝试看看它们是否适合您的场景并根据您的需要进行更改。

将一些逻辑移至您的实体。示例：实体应该能够知道是否处于良好状态。

Entity.Type = 正方形

Entity.Edges = 3

Entity.IsValid() => False // 正方形有 4 条边

您可以创建多个类来帮助您在代码中添加一些逻辑。在功能/实体中，您可以创建多个验证类，然后执行entity.AddValidation(EdgeValidator) 之类的操作。
如果您将根据条件使用不同的算法，您可以使用Strategy Pattern，即Behavioral patterns。

如果 House.FamilySize == 1 那么 ProcessAlgorithm = SinglePersonAlgorithm

Else ProcessAlgorithm = MultiplePersonAlgorithm

过程算法（房子）

旧式和经典式将一个函数拆分为多个函数。

【讨论】：

您可以创建多个类来帮助您在代码中添加一些逻辑。但是我可以在哪里保留这些课程？
@AlexKvitchastiy 他们有很多答案。基本上，这取决于您正在制作的课程和上下文。如果是验证器，您可以拥有一个validators 文件夹；也许是helpers里面的帮手；或者也许它是某种为您的订单实现某些行为的类。如果是这样的话，我会把那个班级放在一个特殊的地方，那里所有的班级都会出现。我认为它将与核心项目中的服务处于同一水平。
@AlexKvitchastiy 忘了说为什么你应该将逻辑转移到你的实体中。在理想世界中，他们应该知道自己的有效状态是什么。如果有一些过程可以基于一个实体获得一些价值，它应该是负责的。现在，如果您有一些业务逻辑，您可以将其放入服务中，以便它知道业务应该如何工作。

【解决方案2】：

将if 语句的不同分支封装在不同的类中可能需要一些返工和重构，但很可能会带来很好的结果，并允许您使用诸如示例之类的模式

责任链
流水线处理

最终所有其他Behavioral patterns

【讨论】：