我刚刚开始使用 MVC，一旦我设法将我的想法转变为它，它似乎将是一个很好的方法。
我遇到的大多数材料似乎在模型、视图和表之间具有 1-1 的关系——即每个模型代表一个表并允许 CRUD，以及更复杂的功能。
如果我有一个允许创建和更新帐户的帐户模型怎么办？
我想使用 /signup 视图和控制器来创建（）帐户，但想使用 /members/account 视图和控制器来更新、更改密码等。
拥有一个注册模型会更好，还是我可以从多个位置使用我需要的任何模型？
另外，假设一个帐户可以有很多用户，但我想在注册时创建第一个用户。我想将帐户设置和用户创建作为事务运行。我应该有一个帐户模型和用户模型，并同时使用两者，还是只让帐户的注册创建（）函数创建默认用户？
我正在将 PHP 与 CodeIgniter 一起使用
一般来说，您最有可能将您的表格视为模型下方的附加“层”；MVC 概念一般不会过多处理支持问题的实现；即您是否使用数据库表或平面文件存储或内存数据表示。
我的建议是将问题视为具有在表和应用程序之间进行交互的一层的问题之一；您的“数据对象”层。将其视为纯序列化。如果您使用的是对象模型，这将是您的 ORM 层。
然后你想要另一个定义“业务逻辑”的层；即您的数据与您的数据的交互。这与帐户如何与用户交互等有关。这里的封装基本上处理了您的高级交互。通过这种方式，您可以定义对您的业务需求最有意义的抽象，而无需依赖于实现；例如，您可以定义一个“UserAccount”模型，它将完成处理用户帐户所需的所有事情；定义您希望该抽象执行的所有操作。然后，一旦你把那个抽象下来，那就是你的模型；然后，您可以在该模型的内部工作中定义交互如何与您的持久性代码发生。
通过这种方式，您可以从实际的模型接口中抽象出模型的持久性和实现。因此，您可以将模型定义为执行您希望它执行的操作，而无需关心底层实现。这样做的好处是显着的；思考你想让你的模型做什么的过程，独立于它将做它的方式，可能是非常有指导意义的；同样，如果您的支持数据层发生更改，您的模型也不需要更改；例如，您可以使用平面文件进行原型设计。