谁用MVC/MVP与数据库通信？

Question

我正在构建一个小型应用程序，并希望将业务对象保存到数据库中。

我有我的业务对象和模型，它充当业务对象的容器，并提供创建和删除它们的方法。更新业务对象是通过直接更改对象属性来完成的。我还有一个用户界面和一个用于用户交互的演示器，还有一个知道如何将我的业务对象插入/删除/更新到数据库中的数据库通信器。

如果业务对象被创建、删除或更改，我希望不断更新我的数据库。

最简单的方法是向我的模型提供对数据库通信器的引用，并在模型中创建/删除业务对象时调用insert/delete方法，并在用户通过用户界面更改业务对象属性时从我的演示程序调用update方法。

在MVP/MVC场景中，这是一种可以接受的处理数据库的方法吗?还是在数据库和模型层之间通常存在更紧密的耦合？如果是这样的话，是否有最佳实践让我的模型知道其中一个业务对象已经改变了，或者我是否只是使用im使用的语言提供给我的任何语言呢？

Answer 1

我见过两种方法。

第一种方法是使用CRUD方法完成所有事情。这基本上就是你描述的方式:创建、读取、更新和删除。大多数对象关系映射器(ORM)支持这四个操作。

第二种方法是提供一个服务层。服务层公开包含业务操作的方法。反过来，它将这些业务操作转换为适当的CRUD方法。

在这一点上，讨论一下体系结构可能是有用的。

首先，请注意MVC和MVP主要是关于UI的。也就是说，他们并不特别关心业务领域发生的事情。虽然UI可以并且经常反映业务域的性质，但它所显示的数据以及它与用户的交互，则是在MVC或MVP的模型部分完成的。

在网页中，MVC通常如下所示：

Model <--> Controller <--> View

模型是这些模式的“其他一切”部分，与UI或路由或其他任何机制无关的部分。你可能听过“瘦控制器，胖模型”这句话。这意味着业务逻辑不会进入控制器。反过来，大多数情况下，视图本身并不关心数据。它只是一个表面；用数据填充它的任务通常落在一个ViewModel对象上，该对象通常由来自模型的数据组装在Controller中。

Model <--> Controller <--> ViewModel <--> View

视图显示数据并接受用户输入的数据。它可能具有一些交互和验证功能，但即使是验证也不能完全在客户机中执行(因为来自客户端的数据不能被信任)。验证被降级到服务器，在服务器中，Controller (主要充当交换场)通常将此类验证委托给模型。

换句话说，大多数实际执行任何有用操作的应用程序逻辑都被推后到模型上。

由于所有这些原因，MV*应用程序通常都有某种服务层，即使它只是内部层。

Database <--> ORM <--> Service Layer <--> Controller <--> View Model <--> View
|-------------- Model -------------|

服务层使Controller不必考虑业务逻辑，并且允许您的数据库通信器(即ORM)只考虑CRUD。

进一步阅读

监管局P:服务层

UI体系结构的Fowler