MVC：逻辑应该放在模型层还是服务层？答案

【问题标题】：MVC: Should logic be placed in the Model or Service layer?MVC：逻辑应该放在模型层还是服务层？
【发布时间】：2023-04-07 22:33:01
【问题描述】：

最近我和一位同事聊了聊模型视图控制器范式。我们正在讨论文件的适当组织等，我提到我认为“瘦控制器和胖模型”是要走的路。这意味着控制器只调用包含业务逻辑的“胖模型”方法：

public class CreditCard {
    //instance vars
    //constructor
    //getters
    //setters (if you want mutability)

    public boolean makeCreditCardPayment(Cart cart) {
    //implementation details...
    }   
}

我的同事另有提及。他说这些模型不应该真的很“胖”并且包含任何其他业务逻辑。该模型应该只是一个数据结构并包含零个方法（显然，如果您使用 Java，则需要 setter 和 getter）。就像 C 风格的结构一样，显然数据字段具有修改器和访问器：

public class CreditCard {
    //instance vars
    //constructor
    //getters
    //setters (if you want mutability)
}


public class PaymentService {
    public boolean makeCreditCardPayment(CreditCard card, Cart cart) {
    //implementation details...
    }   

    public boolean makePayPalPayment(PayPal paypal, Cart cart){
    //implementation details...
    }

甚至为实现接口的每种支付类型都有一个 PaymentService。所以像“CreditCardPaymentService 实现付款”或“PayPalPaymentService 实现付款”之类的东西。

对我来说，使用服务方法的方式似乎我们只是回到了过程式编程。

另一个例子是带有 getSpeed 方法的“Vehicle”对象，与接受 Vehicle 对象并返回速度的服务相比。

我查看了其他 stackoverflow 答案，但他们有不同的答案。在一个问题中，其中一位用户提到服务层是 MVC 的模型部分的一部分。我正在寻找其他答案。

【问题讨论】：

标签： model-view-controller

【解决方案1】：

我遇到过许多声称属于 MVC 范畴的不同哲学。

我的立场：

模型直接管理某种后备存储，并且应该包含变异和验证逻辑。

控制器对于其他控制器和视图来说应该看起来像一个模型（使它们可组合），并且包含验证从控制器接口到模型接口的映射所需的任何额外逻辑。

视图只包含它们运行所需的任何状态和逻辑；它们的目的是显示数据和收集输入。

看起来您的 PaymentService 正试图成为多个控制器，所以我将采用单独的 CreditCardPaymentService 和 PayPalPaymentService 路线。

【讨论】：