Model view controller 确定什么是业务，什么是应用程序逻辑

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

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

业务逻辑 我听到的一个方法是把商业逻辑看作是一种可以被编程无关的人所描述的东西，而只是试图解释一切都是如何运作的。这基本上涉及到要显示的各种数据以及如何处理这些数据（对吗？）

例如，设计计算器应用程序“业务人员”会说，我们的输入将有两个数字，当用户按下“计算”按钮时，我们将使用给定的输入执行某些操作（为简单起见，让我们说添加它们），并将结果输出到“结果”标签中

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

主要问题 现在，如果您使用相同的方法来确定业务和应用程序逻辑的位置，那么主要的问题是。请注意，我没有指定应用程序逻辑实际涉及的内容。这是因为，如果你这样想的话，就真的不清楚应用程序逻辑可能涉及什么，也可能不涉及什么，因为不同的“业务人员”在描述某个应用程序时可能包含或可能不包含各种内容，这使得这种方法在没有某种限制的情况下无法实际使用

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

示例（如果您仍然不清楚问题，请阅读本节） 模糊不清的例子有：

• 在描述时，“商务人士”可能会提到，也可能不会提到：
  • 表单验证
  • 数据库交互
  • 实际上，任何类型的数据操作都会让开发人员感到困扰，但非开发人员会对其进行标注，因为他们意识到这是系统正常运行所必需的

让我们回到我们的计算器应用程序。非开发人员给出的描述可以用伪代码转换为模型，如下所示：

Class CalculatorModel extends Model
{
  public int firstNumber;
  public int secondNumber;
  public int result;

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

然后控制器将如下所示：

Class CalculatorController extends Controller
{
  public void onCalculateButtonClick()
  {
    this->model->calculate();
  }
}

让我们忽略一下，业务部门说单击时我们应该执行计算，我们将该部分放在控制器中，用于应用程序逻辑，因为MVC声明控制器必须处理这类事情，所以我们有不同的问题-我们在哪里更新第一个和第二个

数字

字段？如果使用这种方法，那么它就会变得不清楚，因为不同的人可能会也可能不会提到它，这使得它既不是业务，也不是应用程序逻辑，或者两者都不是，这当然没有任何意义

如果我们想象业务部门在计算之前没有提到我们正在更新任何数字（但我们意识到必须这样做才能进行任何计算），那么我们将确定这确实是应用程序逻辑，并将代码放在控制器中：

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();
 }
}

但是，如果业务部门自己提到，在进行计算之前，我们应该更新第一个和第二个数字，这将被视为业务逻辑，并相应地应用到模型中。此时，我们还有另外两个选项，它们是将字段更新直接添加到

calculate

方法中，或者在我们的模型中创建单独的方法，以便我们可以在调用

calculate（）

之前从控制器调用它

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

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

---

我希望我已经说清楚了，您可以完全理解这个问题，以便能够帮助和/或就使用Model View Controller设计应用程序的正确方法发表您的意见。

如果您正在编写新的不同平台上的应用程序。如果您要移植到客户端应用程序而不是web应用程序，这仍然是有用的逻辑吗

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

---

以存储计算为例，这就是业务逻辑。但存储方式更具体于应用程序。这就是人们最终创建DAO对象之类的东西的地方。具有存储计算的特定于应用程序的方法。这可以将存储的业务逻辑与存储在数据库中的业务逻辑（明天可能是一个日志文件或某个web服务）分开。

通过thi将业务逻辑与应用程序逻辑分开要容易得多