Multiple Table Models with MVC?

Question

Hi All,

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.

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.

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?

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?

I am using PHP with CodeIgniter

Answer 1

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.

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.

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.