【问题标题】:Determining what is business and what is application logic确定什么是业务,什么是应用程序逻辑
【发布时间】:2023-03-20 10:29:01
【问题描述】:

我是这些概念的新手,目前正在尝试了解我正在使用 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 声明控制器必须处理这些事情,无论如何我们都有不同的问题 - 我们在哪里更新firstsecond Number 字段?如果使用这种方法,那么它就变得不清楚了,因为不同的人可能会也可能不会提到它,这使得它既不是业务,也不是应用程序逻辑,或者两者都没有任何意义。

如果我们想象业务没有提到我们在计算之前更新任何数字(但我们意识到必须完成它才能进行任何计算),那么我们会确定它确实是应用程序逻辑并且会在控制器中放置代码:

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

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

企业也可能会或可能不会提及在执行任何操作之前是否应验证用户输入,但如果用户在输入时给出两个非数字,则将无法计算,因此您必须实施它并且您必须知道将其放在哪里它。

假设有一天,您的客户告诉您,他们希望将计算的每个结果存储在某个地方,然后能够以某种方式进行查看。这意味着您应该向数据库发送请求,但是由于他们没有确切地提到它必须是数据库,因此再次不清楚将代码放在哪里。

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

【问题讨论】:

    标签: model-view-controller architecture language-agnostic business-logic concept


    【解决方案1】:

    如果您在不同平台上编写新应用程序,考虑是否要保留此逻辑,将业务逻辑与应用程序逻辑分开会容易得多。如果您要移植到客户端应用程序而不是 Web 应用程序,这仍然是有用的逻辑吗?

    如果它在新的上下文中没有用,那么逻辑是特定于应用程序的。如果能再用,就是业务逻辑。

    以存储计算为例,这就是业务逻辑。但是你如何存储它是更特定于应用程序的。这就是人们最终创建诸如 DAO 对象之类的东西的地方。具有用于存储计算的应用程序特定方法。这将您存储它的事实与将其存储在数据库中的事实(明天它可能是一个日志文件或某些 Web 服务)分开。

    【讨论】:

    • 这是一种有趣的思考方式,我将尝试以这种方式设计我的应用程序一段时间,然后看看效果如何。而 DAO 类实际上正是我所拥有的,所以我理解你在说什么,对 DAO 的调用被认为是业务逻辑,应该放入模型中,但 DAO 本身是一个单独的东西,应该作为应用程序逻辑,但是因为我们只从模型中调用 DAO 就可以了,对吧?因此,例如,以下代码将被视为业务逻辑并被放入模型中? if(!DAO::tableExists()) DAO::createtable();
    • 另外,您对 MVC 的这种想法有何看法?将应用逻辑完全放在控制器内部,将业务逻辑完全放在模型内部是否正确?
    • 不,我认为表创建是特定于应用程序的。不是业务逻辑。运行此应用程序需要管道。再一次,如果您开始将日志保存到 Web 服务,那么它是否无关紧要,那么它是应用程序逻辑,而不是业务逻辑。这是在引导时应该让 DAO 自己调用的那种逻辑。
    猜你喜欢
    • 2011-03-17
    • 2011-09-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-09-07
    • 2015-11-10
    • 2020-04-14
    • 1970-01-01
    相关资源
    最近更新 更多