代码之家 › 专栏 › 技术社区 › Eli

使用MVC的多表模型?

model architecture model-view-controller

3

Eli · 技术社区 · 17 年前

我刚刚开始使用MVC,一旦我设法将思维转向它,它似乎将是一条很好的路要走。

我遇到的大多数材料似乎在模型、视图和表之间都有1:1的关系——即每个模型代表一个表,允许CRUD,以及更复杂的功能。

如果我有一个帐户模型,可以创建和更新帐户,该怎么办。

我想使用/signup视图和控制器来创建()帐户,但想使用/remembers/account视图和控制器更新、更改pw等。

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

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

我使用PHP和CodeIgniter

1 回复 | 直到 17 年前

1

4

Paul Sonier 17 年前

一般来说,您最想做的是将表视为模型下方的一个额外“层”;MVC概念通常不会过多地处理支持问题的实现;即,无论您是否使用DB表或平面文件存储或内存中的数据表示。

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

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

通过这种方式,你抽象出 坚持不懈 和实施从实际模型中提取您的模型界面因此,您可以将模型定义为做您想做的事情,而不必担心底层实现。这样做的好处是巨大的;思考你希望你的模型做什么的过程,与它将要做的方式分开,可能非常有指导意义;同样,如果你的支持数据层发生了变化,你的模型也不需要改变;例如,您可以使用平面文件进行原型制作。