Multiple table models with MVC?

Question

I am just starting to work with MVC, and it seems that this will be a great way, as soon as I manage to switch my thinking.

Most of the material I came across seems to have a 1-1 relationship between models, views and tables - i.e. each model is a table and allows CRUD, as well as more complex functions.

What if I have an account model that will allow you to create and update accounts.

I would like to use the view / controller to register and the controller to create () an account, but I would like to use the view / members / account and controller to update, change pw, etc.

Would it be better to have a registration model, or am I fine using only the model that I need from several places?

In addition, let's say an account can have many users, but I want to create the first user during registration. I would like to start setting up an account and creating a user as a transaction. Should I have an account model and a user model and work with both, or just have the signup create () function for the account to create the default user?

I am using PHP with CodeIgniter

Answer 1

In general, what you want to do is likely to consider your tables as an additional “layer” below your model; the concept of MVC, as a rule, is not too closely related to the implementation of support problems; those. whether you use database tables or flat file storage or data representations in memory.

What I would like to suggest is to look at the problem as one layer that interacts between your tables and your application; your data objects layer. Think of it as pure serialization. If you use the object model, this will be your ORM level.

Then you want to have another layer that defines "business logic"; those. the interaction of your data with your data. This is due to how the Account interacts with the user, etc. Encapsulation here will basically take care of your high-level interactions. That way, you can define the abstractions that make the most sense for your business requirements without having to depend on implementation; for example, you can define a UserAccount model that will do everything you need to process user accounts; define everything you want to make an abstraction. Then, when you have this abstraction, this is your model; you can then define in the internal functions of this model how interactions occur with your persistence code.

Thus, you abstract the persistence and implementation of your model from the actual interface . Thus, you can define your model as what you want so that it does not concern the main implementation. The benefits of this are significant; the process of thinking about what you want your Model to do, apart from how she will do it, can be very educational; also, if your background layer of support changes, your model does not need to be changed; so you can prototype with a flat file for example.