MVC 的多表模型? [英] Multiple Table Models with MVC?

问题描述

我刚刚开始使用 MVC，一旦我设法将我的想法转向它，这似乎将是一个很好的方法.

I am just getting started with MVC, and it seems like it will be a great way to go, once I manage to switch my thinking to it.

我遇到的大多数材料似乎在模型、视图和表之间存在 1-1 关系 - 即每个模型代表一个表并允许 CRUD，以及更复杂的功能.

Most of the material I have come across seems to have a 1-1 relationship between models, views, and tables - ie each model represents a table and allows CRUD, plus more complex functions.

如果我有一个允许创建和更新帐户的帐户模型会怎样.

What if I have an Account Model, which would allow account creation and updating.

我想使用/signup 视图和控制器来创建()帐户，但想使用/members/account 视图和控制器来更新、更改密码等.

I would want to use a /signup view and controller to create() the account, but would want to use a /members/account view and controller to update, change pw, etc.

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

Would it be better to have a Signup Model, or am I ok with just using whatever model I need from multiple locations?

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

Also, say an account can have many users, but I want to create the first user at signup. I would like to run the account setup and user creation as a transaction. Should I have an Account Model and User Model, and work with both, or just have the signup create() function for Account create the default user?

我使用 PHP 和 CodeIgniter

I am using PHP with CodeIgniter

推荐答案

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

In general, what you want to do is most likely to consider your tables to be an additional "layer" below your model; the MVC concept generally doesn't deal too much with the implementation of backing issues; i.e. whether or not you're using DB tables or flat file storage or in-memory data representations.

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

What I would suggest is to look at the problem as one of having one layer that does interaction between your tables and your application; your "data objects" layer. Think of this as pure serialization. If you're using an object model, this will be your ORM layer.

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

Then you want to have another layer that defines the "business logic"; i.e. the interaction of your data with your data. This has to do with things such as how the Account interacts with the User, etc. The encapsulation here basically takes care of your high-level interactions. In this way, you can define the abstractions that make the most sense for your business requirements without needing to depend on implementation; for example, you can define a "UserAccount" Model, that will do all the things that you need to do to handle User Accounts; define all the things that you want that abstraction to do. Then, once you've got that abstraction down, that is your Model; you can then define, in the internal workings of that model, how the interactions occur with your persistence code.

通过这种方式，您可以从实际的模型接口中抽象出模型的持久性和实现.因此，您可以将模型定义为做您希望它做的事情，而无需关心底层实现.这样做的好处是显着的；考虑您希望您的模型做什么的过程，与它将执行它的方式分开，可以非常有指导意义；同样，如果您的支持数据层发生变化，您的模型也不需要更改；例如，您可以使用平面文件进行原型设计.

In this way, you abstract out the persistence and implementation of your Model from the actual Model interface. So you can define your model as doing the things you want it to do without concern for the underlying implementation. The benefits of this are significant; the process of thinking about what you want your Model to do, in isolation from the way in which it will be doing it, can be very instructional; as well, if your backing data layer changes, your Model doesn't need to change; so you can prototype with a flat file, for example.

这篇关于MVC 的多表模型?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！