model-view-controller - 使用 MVC 的多表模型？

Question

我刚刚开始使用 MVC，一旦我设法将我的想法转变为它，它似乎会是一个很好的方法。

我遇到的大多数 Material 似乎在模型、 View 和表之间具有 1-1 的关系 - 即每个模型代表一个表并允许 CRUD，以及更复杂的功能。

如果我有一个允许创建和更新帐户的帐户模型怎么办？

我想使用/signup View 和 Controller 来创建()帐户，但想使用/members/account View 和 Controller 来更新、更改密码等。

拥有一个注册模型会更好，还是我可以从多个位置使用我需要的任何模型？

另外，假设一个帐户可以有很多用户，但我想在注册时创建第一个用户。我想将帐户设置和用户创建作为事务运行。我应该有一个账户模型和用户模型，并同时使用两者，还是只让账户的注册 create() 函数创建默认用户？

我正在使用 PHP 和 CodeIgniter

Answer 1

一般来说，您最有可能将表格视为模型下方的附加“层”； MVC 概念通常不会过多地处理支持问题的实现；即您是否使用数据库表或平面文件存储或内存中数据表示。

我的建议是将问题视为在表和应用程序之间进行交互的一层；你的“数据对象”层。将此视为纯序列化。如果您使用的是对象模型，这将是您的 ORM 层。

那么你想要另一个定义“业务逻辑”的层；即您的数据与数据的交互。这与帐户如何与用户交互等有关。这里的封装基本上负责您的高级交互。通过这种方式，您可以定义对您的业务需求最有意义的抽象，而无需依赖于实现；例如，您可以定义一个“UserAccount”模型，它将完成您需要做的所有事情来处理用户帐户；定义您希望该抽象执行的所有操作。然后，一旦你完成了抽象，那就是你的模型；然后，您可以在该模型的内部工作中定义如何与您的持久性代码进行交互。

通过这种方式，您可以从实际的模型界面中抽象出模型的持久性和实现。因此，您可以将模型定义为执行您希望它执行的操作，而无需关心底层实现。这样做的好处是显着的；思考你想要你的模型做什么的过程，独立于它将会做的方式，可以是非常有指导意义的；同样，如果您的支持数据层发生变化，您的模型也不需要改变；例如，您可以使用平面文件制作原型(prototype)。