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