关于模型视图控制器：确定什么是业务，什么是应用程序逻辑


Determining what is business and what is application logic

我对这些概念不熟悉，目前正在尝试理解我使用MVC概念开发的应用程序中的业务和应用程序逻辑。

在我看来，大多数人都同意这样一个事实：应用程序逻辑属于控制器，业务逻辑属于模型。这就是我想要能够确定什么是什么的基本原因，所以在阅读问题时要记住这一点，不要错过要点。

业务逻辑

我听到的一种方法是，将业务逻辑更多地看作是一种可以被那些与编程无关的人描述的东西，而只是试图解释每件事情是如何工作的。所以这基本上涉及到要显示的各种数据以及如何处理这些数据(对吗？).

例如，设计计算器应用程序"Business People"会说我们的输入将有两个数字，当用户按下"Calculate"按钮时，我们将对给定的输入执行某些操作(为了简单起见，我们假设添加它们)，并将结果输出到"Result"标签中。

应用程序逻辑

现在，应用程序逻辑更多的是开发人员关心的事情，更多的是"业务人员"在描述某种类型的项目时往往忽略的事情。

主要问题和问题

如果您使用相同的方法来确定业务在哪里，应用程序逻辑在哪里，那么这里就是主要问题。注意，我没有指定应用程序逻辑实际涉及的内容。这是因为如果你这样想的话，应用程序逻辑可能会涉及到什么，也可能不会涉及到什么，因为不同的"业务人员"在描述某些应用程序时，可能会涉及到或可能不涉及到所有种类的东西，这使得这种方法在没有某种限制的情况下实际上无法使用。

我的问题是，为了能够正确地确定应用程序在哪里，业务逻辑在哪里，或者应该使用什么方法，应该对这种方法应用什么类型的限制？另外，是否真的正确地说控制器是用于应用程序逻辑的，模型是用于业务的，或者它们可以共享两者的某些部分，如果是，那么以何种方式共享？

示例(如果问题仍不清楚，请阅读本节)

模糊的例子有：

  • 在描述时，"商务人士"可以或不可以提及：
    • 表单验证
    • 数据库交互
    • 实际上，任何一种应该困扰开发人员的数据操作，但由于非开发人员意识到系统正常运行是必需的，所以它们被定义为维度。

让我们回到计算器应用程序。非开发人员给出的描述可以用这样的伪代码转换成模型：

1
2
3
4
5
6
7
8
9
10
11
Class CalculatorModel extends Model
{
  public int firstNumber;
  public int secondNumber;
  public int result;

  public void calculate()  
  {
    this->result = this->firstNumber + this->secondNumber;
  }
}

那么控制器应该如下所示：

1
2
3
4
5
6
7
Class CalculatorController extends Controller
{
  public void onCalculateButtonClick()
  {
    this->model->calculate();
  }
}

号

让我们忽略业务部门说过的单击时我们应该执行计算，我们将这部分放在控制器中，这是用于应用程序逻辑的，因为MVC声明控制器必须处理这些事情，我们无论如何都有不同的问题-我们在哪里更新first和secondNumber字段？如果使用这种方法，那么它就变得不清楚了，因为不同的人可能也可能不提它，这使得它既不是业务，也不是应用程序逻辑，或者两者都没有任何意义。

如果我们认为Business没有提到我们在计算之前更新了任何数字(但我们意识到必须进行任何计算)，那么我们将确定它确实是应用程序逻辑，并将代码放在控制器中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Class CalculatorController extends Controller
{
  public void updateNumbers()
  {
    this->model->firstNumber = input1->text;
    this->model->secondNumber = input2->text;
  }

 public void onCalculateButtonClick()
 {
    this->updateNumbers();
    this->model->calculate();
 }
}

但是，如果Business自己提到，我们应该在进行计算之前更新第一个和第二个数字，这将被视为业务逻辑，因此也将被放入模型中。在这一点上，我们还有另外两个选择，即直接将字段更新添加到calculate方法中，或者在我们的模型中创建单独的方法，以便我们可以在调用calculate()之前从控制器调用它。

业务部门也可能会或可能不会提及在执行任何操作之前是否应验证用户输入，但如果用户在输入时给出两个非数字，那么将无法进行计算，因此您必须实现它，并且必须知道将其放在何处。

假设有一天，你的客户告诉你，他们想把每一个计算结果存储在某个地方，然后以某种方式观察它。这意味着您应该将请求发送到数据库，但由于它们没有确切地提到它必须是数据库，所以再次不清楚将代码放在何处。

我希望我已经把自己弄清楚了，你能完全理解这个问题，能够帮助和/或给出你对使用模型视图控件设计应用程序的正确方法的意见。

如果在不同的平台上编写新的应用程序，那么通过考虑是否要保留此逻辑，可以更容易地将业务逻辑与应用程序逻辑分开。如果您要移植到客户端应用程序而不是Web应用程序，这是否仍然是有用的逻辑？

如果它在新的上下文中不有用，那么逻辑是特定于应用程序的。如果您可以再次使用它，它就是业务逻辑。

以存储计算为例，这就是业务逻辑。但是您如何存储它是更具体的应用程序。这就是人们最终创造像DAO对象这样的东西的地方。具有存储计算的特定应用方法。这将使您存储它的事实与您将其存储在数据库中的事实(明天它可能是日志文件或某些Web服务)保持分离。

相关讨论