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

Question

我是这些概念的新手，目前正在尝试理解我正在使用MVC概念开发的应用程序中的业务和应用程序逻辑是什么。

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

我听到的一种方法是将业务逻辑更多地视为一种可以由那些与编程无关的人来描述的东西，而这些人只是试图解释一切将如何工作。所以这基本上涉及到要显示的各种数据，以及如何处理这些数据（对吗？）。

例如，在设计计算器应用程序时，“Business People”会说，我们的输入中有两个数字，当用户按下“Calculate”按钮时，我们会对给定的输入执行某些操作（为了简单起见，让我们把它们相加），并将结果输出到“result”标签中。

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

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

我的问题是，为了能够正确确定应用程序和业务逻辑的位置，应该对这种方法应用什么样的限制，或者应该使用什么方法？另外，说controller用于应用程序逻辑，model用于业务是否正确，或者它们是否可以共享两者的某些部分？如果是，那么以哪种方式共享？

晦涩难懂的例子有：

• “商务人士”在描述时，可能会提到，也可能不会提到：
  • 表单验证
  • 数据库交互
  • 任何类型的数据操作都应该困扰开发人员，但由于非开发人员意识到系统正常运行需要这些操作，他们就会采用这种操作

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

  Class CalculatorModel extends Model
  {
    public int firstNumber;
    public int secondNumber;
    public int result;
  
    public void calculate()  
    {
      this->result = this->firstNumber + this->secondNumber;
    }
  }
  

  则controller将如下所示：

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

  但是如果business自己提到，我们应该在进行计算之前更新第一个和第二个数字，那么就会被认为是业务逻辑，并相应地被放入模型中。此时，我们有另外两个选项，它们是将字段update直接添加到calculate方法中，或者在我们的模型中创建单独的方法，以便在调用calculate()之前从controller调用它。

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

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

  我希望我已经讲清楚了，您可以完全理解这个问题，以便能够帮助和/或提供您关于使用模型-视图-控制器设计应用程序的正确方法的意见。

Answer 1

如果您在不同的平台上编写新的应用程序，那么将业务逻辑和应用程序逻辑分离开来就会容易得多。如果您要移植到客户端应用程序而不是Web应用程序，那么这仍然是有用的逻辑吗？

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

以存储计算为例，这就是业务逻辑。但如何存储它更多地是特定于应用程序的。这就是人们最终创建像DAO对象这样的东西的地方。以具有存储计算的特定应用程序方法。这使得您存储它的事实与您将它存储在数据库中的事实（明天它可能是日志文件或某个web服务）之间保持了分离。