How to model correctly: object-oriented or "batch" -oriented?

Question

I know that in OOP you want each object (from a class) to be a "thing", for example. user, validator, etc.

I know the basics of MVC, how they interact with each other.

However, I am wondering if MVC models should be developed in accordance with the traditional design of OOP, i.e. should each model be a base / table / row (solution 2)?

Or is it more like collecting methods that affect the same table or a bunch of related tables (solution 1).

example for the address book module in CodeIgniter, where I want to be able to "CRUD" a Contact and add / remove it to / from the contact group accessible by CRUD.

Model 1 Solution: Combining all related methods (not a real object, but rather a “package”)

class Contacts extends Model { function create_contact() {) function read_contact() {} function update_contact() {} function delete_contact() {} function add_contact_to_group() {} function delete_contact_from_group() {} function create_group() {} function read_group() {} function update_group() {} function delete_group() {} } 

Model 2 Solution: OOP Method (One Class for Each File)

 class Contact extends Model { private $name = ''; private $id = ''; function create_contact() {) function read_contact() {} function update_contact() {} function delete_contact() {} } class ContactGroup extends Model { private $name = ''; private $id = ''; function add_contact_to_group() {} function delete_contact_from_group() {} function create_group() {} function read_group() {} function update_group() {} function delete_group() {} } 

I do not know how to think when I want to create models. and the examples above are my real tasks in creating an address book. Should I just combine all the functions in one class. then the class contains different logic (contact and group), so it cannot save properties that are specific to any of them.

Solution 2 works in accordance with OOP. but I do not know why I should make such a separation. what advantages will be, for example, a contact object. This is certainly not a User object, so why would Contact live with its own state (properties and methods). Because I tend to think this way: if something needs a state, then I create an OOP class so that methods can influence state or other things based on state.

so should the models be “in terms of state”? if they do not require state, why should I create it according to the OOP pattern. then I could just put it all together as a package solution.

you had experienced guys with OOP / MVC, please clarify how you should think here in this specific task (and generally when creating a model).

EDIT: Think about controllers in MVC. they are created in accordance with the solution "package". It makes me think ...

Answer 1

should each model be a database / table / row (solution 2)?

Not. Do not associate the definition of a model with its persistence method. Although for simple applications you can extend the model from a database row object, you should keep them at least mentally separate.

Models are simply representations of objects in your domain, so they have a state if necessary. Where you are talking about the Contact model, you are really talking about a crankcase or gateway, i.e. About how an object retrieves your model from a data warehouse. It is sad that so many special implementations of Active Record have polluted the waters on it.

Mappers can be implemented as a set of static functions or as an object, however the collection is less flexible if you want to expand or change the behavior for any reason (for example, to mock unit testing).

The model itself should be just a set of data, either stored as public properties, or preferably with the corresponding setters and getters (please do not just define a pair of get / set functions for each variable, or you can just leave them public), as well as other methods, that work with data. He should not have any idea about the data warehouse or its dependency. The responsibility for creating and initializing the model through the user interface lies with the developer. This will provide flexibility in how you can create and save your models. You can do this from a database, an XML file, an intra-code, from a serialized stream sent over the network, regardless of what your boat is sailing, all by replacing another cartographer, and the model remains completely unconscious.

Answer 2

I don’t know if there is a better way , but I will share how I do it ...

I have a table gateway, for example. ContactTableGateway, which contains all sql for working with contacts. I like that all sql are in one place.

 class ContactTableGateway extends Model { function saveContact( Contact $contact ) function getContact ( $contact_id ) function createContact ( Contact $contact ) } 

Then I have a contact class that basically only has recipients and setters (or public properties). Objects of this class are used as arguments to the table gateway for saving / creating

 class Contact extends Model { function getName() function getAddress() function getEmail() .... } 

Here is a simplified example

 if ( isset( $_POST ) ) { // some validation here $contact = new Contact; $contact->name = $_POST['name']; $contact->email = $_POST['email'] $contactTableGateway = new ContactTableGateway; if ( $contactTableGateway->createContact( $contact ) ) { echo "YAY"; } } 

Answer 3

I think your solution # 2 is superior to it, more molecular / modular, therefore more understandable, flexible and expandable (in the OOP domain). It is also more resource-friendly, as it can only allow you to load the Contact class if there is no need for contact group functionality and vice versa. This is the advantage of separation.

If the models do not need state, this does not mean that OOP / MVC is not applied. Table models may not have state in one design, but therefore we have static methods / members, i.e. Contact :: read ($ id).