1

It's the first time I'm using an PHP framework and I have a question regarding this design pattern.

Let's say I'm trying to build an php app that has a contact us page (which will ask for the name, email address comment etc and once submitted it will simply use the mail function to send an email to the admin). I know what my view is gonna be, I will also use a controller to render the view, but what should be my model? I'm not going to load anything from the database or save anything to the database. So in this case should I skip the model?

tereško
  • 58,060
  • 25
  • 98
  • 150
Josh
  • 692
  • 2
  • 9
  • 38

4 Answers4

2

I’d say that, even with a contact form, a model has its use.

A contact form handles enquiries, a contact form has fields, and a contact form usually requires some form of validation. This can be wrapped up in an Enquiry model.

In fact, this is exactly what I do with CakePHP applications. I have an Enquiry model that defines the fields and data validation, and saves any enquiries to the database (for archiving purposes) and has an afterSave callback method that sends me the enquiry details via email. I’m sure you could do something analogous in CodeIgniter.

Martin Bean
  • 38,379
  • 25
  • 128
  • 201
  • there is one thing I don't get it, according to: http://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc model should contains the business logic, so let's say I created a model for validation purpose, shouldn't the logic sit in the model? (ie. controller calls a model function to validate, instead of the controller doing it instead)? please advise – Josh Sep 25 '13 at 14:45
  • Yes, validation logic should live within the model. The controller should call the validation method, but the actual logic should be within your model. – Martin Bean Sep 25 '13 at 14:58
1

Models are optional in Codeigniter. If you don't need one then don't use one.

Models are optionally available for those who want to use a more traditional MVC approach.

Documentation

In your particular case you have no need of a model so don't worry about making one.

Bad Wolf
  • 8,206
  • 4
  • 34
  • 44
  • 1
    respectfully do not agree with either of these, please see my answer (and what martin just posted). – cartalot Sep 24 '13 at 19:28
1

the gritty details go in the model. even a simple contact form has lots of gritty specific details: names of fields, specific validation rules, etc.

the controller is the boss - validate this form! it does not say how to validate it, and it doesn't need the details of each field in the form. if the form validates - the controller calls the next view. if it does not validate - then the controller shows the form again and maybe passes specific error messages.

  • the validation details for the contact form - put that in a model.

  • the emailing of the form: the content of the email, taking the form values and putting it into the email, who the email goes to, the details of actually sending the email - that is all work for a model.

what does this gain us? when your client calls in a year and says - change the text in the email - you won't be hunting through a bunch of controller code. you will look at your model names and know exactly where to go. separation of concerns is not just for building - its for the inevitable changes that happen over time.

EDIT

yes the business logic should be in the model. so like for a contact form the business rules might be - we ask for name and address - and we require the email address and phone number. the validation rules then fulfill the business rules.

then six months later your client calls and says - well people don't like us requiring the phone number - just make the email required. you have put those validation rules in your model - therefore it is only that specific model which needs to change. the controller does not change at all! and since you separated the form validation rules from the sending of the email into separate models - if you make a mistake when changing the validation rule - its much less code to look through and debug.

the other way to look at is - how specific and 'granular' is the method? the more specific it is, the further from the controller it should be. the controller methods should rarely change because of changes to business rules.

so when i said the controller orders "validate this form" - i just meant that the controller is calling the validation method that is in the model, and then its getting back true or false, no matter what changes happen to the form over time.

cartalot
  • 3,147
  • 1
  • 16
  • 14
  • there is one thing I don't get it, according to: http://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc model should contains the business logic, so let's say I created a model for validation purpose, shouldn't the logic sit in the model? (ie. controller calls a model function to validate, instead of the controller doing it instead)? please advisea – Josh Sep 25 '13 at 14:44
0

OP here, just want to do a quick update on this.

I have looked at CodeIgniter's documentation, and surprisingly found out that the form validation code is inside the controller:

http://ellislab.com/codeigniter/user-guide/libraries/form_validation.html#validationrules

which IMO is not a good idea.

Fortunately, there is a way to clean up the controller, which requires you to create a form validation config file inside the config folder:

http://ellislab.com/codeigniter/user-guide/libraries/form_validation.html#savingtoconfig

since I don't want to reinvent the wheel, I guess I will just create the config file without creating the model

Josh
  • 692
  • 2
  • 9
  • 38