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