首页 文章

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

提问于
浏览
0

我是这些概念的新手,目前正试图了解我正在使用MVC概念开发的应用程序中的业务和应用程序逻辑 .

在我看来,大多数人都同意应用程序逻辑属于控制器而业务逻辑属于模型 . 这基本上是我希望能够确定什么是什么的原因,所以在阅读问题时要记住这一点,不要错过这一点 .

业务逻辑

我听过的一种方法是将业务逻辑视为一种可以由与编程无关的人描述的东西,只是试图解释一切是如何工作的 . 这基本上涉及要显示的各种数据以及如何处理数据(对吗?) .

因此,例如设计计算器应用程序“业务人员”会说我们将在输入处输入两个数字,当用户按下“计算”按钮时,我们将使用给定输入执行某些操作(为简单起见,我们假设添加它们),以及将结果输出到“Result”标签中 .

应用逻辑

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

主要问题和疑问

现在's the main problem if you'使用相同的方法来确定业务的位置以及应用程序逻辑的位置 . 请注意,我没有指定实际应用程序逻辑涉及的内容 . 这是因为如果你这样思考它真的变得不清楚什么应用程序逻辑可能会或可能不会涉及因为不同的"business people"可能会或可能不会包含所有类型的东西,同时描述一些应用程序,这使得这种方法实际上无法使用限制 .

我的问题是,应该对这种方法应用哪种限制,以便能够正确确定应用程序的位置以及业务逻辑在哪里 or 应该使用哪种方法?也就是说控制器是用于应用程序逻辑并且模型是用于业务还是它们可以共享两者的某些部分,如果是,那么以哪种方式呢?

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

默默无闻的例子是:

  • 在描述时,"business people"可能会或可能不会提及:

  • 表单验证

  • 数据库交互

  • 实际上任何类型的数据操作都应该打扰开发人员,但是非开发人员会因为他们意识到需要系统才能正常运行

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

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

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

在执行任何操作之前,业务也可能提及或者可能没有提及是否应该验证用户输入,但是如果用户在输入处输入两个非数字,那么将无法进行计算,因此您必须实现它并且您必须知道将其放在何处 .

让我们说有一天你的客户告诉你他们想要在某处存储计算的每一个结果,然后能够以某种方式观察它 . 那意味着你应该向数据库发送请求,但由于他们没有确切地提到它必须是数据库,所以再次不清楚在哪里放置代码 .

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

1 回答

  • 3

    如果您想在不同平台上编写新应用程序时想要保留此逻辑,则可以更轻松地将业务逻辑与应用程序逻辑分离 . 如果您移植到客户端应用程序而不是Web应用程序,这仍然是有用的逻辑吗?

    如果它在新上下文中没用,那么逻辑就是特定于应用程序的 . 如果你可以再次使用它,那就是业务逻辑 .

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

相关问题