ilyatom Asked:2023-06-14 16:29:58 +0000 UTC2023-06-14 16:29:58 +0000 UTC 2023-06-14 16:29:58 +0000 UTC MVC 中的模型耦合 772 我试图最终理解模型-视图-控制器模式。显然，所有业务逻辑最好放在模型中以避免“又胖又笨又丑的控制器”。但是同时接触多个模型的方法呢？ 假设结帐会影响订单模型、产品、用户、交付、折扣。如果我们决定将业务逻辑放在模型中，结帐方法将存储在哪里以及使用相关模型的正确方法是什么？将他们的对象作为参数传递？ 还是应该将与许多模型相关的功能移到一个单独的类中？如果是这样，在不违反 MVC 原则的情况下，我应该将它放在应用程序结构中的什么位置？ 帮助我理解。 mvc 1 个回答 Voted Best Answer Александр Окостень 2023-06-14T17:02:29Z2023-06-14T17:02:29Z 还是应该将与许多模型相关的功能移到一个单独的类中？如果是这样，在不违反 MVC 原则的情况下，我应该将它放在应用程序结构中的什么位置？ 在这种情况下，可以使用以下方法： 将与多个模型关联的方法放在其中一个模型中： 创建一个单独的类或服务层来处理相关模型： 如果功能跨越多个模型并且不是其中之一的直接责任，您可以创建一个单独的类或服务层来对相关模型执行操作。这个类可以包含与业务逻辑相关的方法，并通过它们的接口与各种模型一起工作。这种方法有助于避免使用与其主要职责无关的功能使模型过载。需要注意的是，在 MVC 中，模型不一定只是一个类，它可以是一组相关的类或组件。最主要的是业务逻辑和数据责任应该相互关联并逻辑组织。 要完全消除控制器中的逻辑或其中一个模型中的工作负载，请使用服务与同一类中的不同实体进行交互。这些服务可以存储在类库中，并命名为yourProjectName.Data -> Services -> CheckoutService 反过来， CheckoutService将包括下订单所需的所有实体的交互
在这种情况下，可以使用以下方法：
将与多个模型关联的方法放在其中一个模型中：
创建一个单独的类或服务层来处理相关模型：
如果功能跨越多个模型并且不是其中之一的直接责任，您可以创建一个单独的类或服务层来对相关模型执行操作。这个类可以包含与业务逻辑相关的方法，并通过它们的接口与各种模型一起工作。这种方法有助于避免使用与其主要职责无关的功能使模型过载。需要注意的是，在 MVC 中，模型不一定只是一个类，它可以是一组相关的类或组件。最主要的是业务逻辑和数据责任应该相互关联并逻辑组织。
要完全消除控制器中的逻辑或其中一个模型中的工作负载，请使用服务与同一类中的不同实体进行交互。这些服务可以存储在类库中，并命名为yourProjectName.Data -> Services -> CheckoutService 反过来， CheckoutService将包括下订单所需的所有实体的交互