Mapping MVC to Customer Registration

Tom_Tees

I have been reading a fair amount about Model-View-Controller (MVC), and am still confused what each is supposed to do. (There doesn't seem to be as much consensus as you'd expect on such a common pattern?!)

I'm trying to build an e-commerce site from scratch, have my website sketched out on paper, and have detailed use-cases.

In order to "get my feet wet" with PHP, OOP, and MVC, I am trying to code just a small portion of the larger site by building the "Customer Registration module".

Here is what I have so far...

Customer table:
- id
- username
- password
- first_name
- last_name
- address
- city
- state
- zip
- tele_no

Registration process: (simplified)
- A "User" can be a "Visitor" or "Customer".
- A "Visitor" decides to Register and become a "Customer"
- The System asks for a Username (E-mail), Password, and AcceptTermsYN.
- The User enters a Username, Password, and Accepts the Terms.
- The System ensures the Username is unique.
- The System ensures Usernames match.
- The System ensures the Passwords match.
- The System ensures the User accepted the "Terms".
- The System creates a new Customer Account (record).
- The System sends an "Activation E-mail" to the User's E-mail.
- The User clicks on a link in the e-mail.
- The System confirms the e-mail is valid (i.e. receives response back)
- The System activates the Customer's Account.
- The "Visitor" is now a registered "Customer".

Customer class:
(same as "Customer" table)

Registration class:
Properties:
- username
- password

- accept_terms

Methods:
- checkUsernameUnique()
- checkUsernameValid()
- checkPasswordValid()
- checkAcceptTerms()
- createCustomerAccount()
- sendActivationEmail()
- activateCustomerAccount()

Comments:
Registration only requires working with Username, Password, and AcceptTermsYN. It is not until "Checkout" that the additional fields in the Customer class/table are needed.

I have been told that...

class Customer == Model
class Registration == Controller
form Registration == View

This is what I have found online for definitions of each...

MODEL:
- "Represents enterprise data and the business rules that govern access to and updates of this data."

"Often serves as a software approximation to a real-world process."
"The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller)."

CONTROLLER:
- "A Controller accepts input from the user and instructs the Model and Viewport to perform actions based on that input."

"The Controller receives GET or POST input and decides what to do with it, handing over to domain objects (i.e. the Model)"
"The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate."

This leads me to believe that...

class Registration (and maybe class Customer) == Model
??? == Controller
form Registration == View

QUESTIONS:

1.) What is the Controller in my example above?

2.) What is the Model in my example above?

3.) Does my design look okay so far?

(I do believe that "Registration" needs to be its own class since it is a process/service that is logically separate from a "Customer".)

TomTees

NogDog

My immediate take on this would be that I would have:

Customer_user class: Model that defines a customer user*
Customer_validation class: Model that defines how to validate customer data**
Customer_registration class: Controller that uses both the above models as needed to control the registration process
Customer registration form: View
Customer registration success: View

Mainly deals with creating/reading/updating/deleting (CRUD) data for a customer
** This would provide the methods/data needed to validate customer data inputs

I would not get too hung up on the controller doing things that sound like business logic. What much of your use case describes is not business logic, but application logic: i.e. the business itself does not really care if the customer validation is done by an email link or by phone call; it only cares that new customer accounts can be created. Therefore I have no problem with doing a lot of the registration logic within the controller.

Tom_Tees

NogDog;10955133 wrote:
I would not get too hung up on the controller doing things that sound like business logic. What much of your use case describes is not business logic, but application logic: i.e. the business itself does not really care if the customer validation is done by an email link or by phone call; it only cares that new customer accounts can be created. Therefore I have no problem with doing a lot of the registration logic within the controller.

That is a very good, and new point to ponder. (It doesn't make me any less confused, though!) 🙂

Yes, NogDog, I suppose my "application logic" to register a user isn't really "business logic".

At the same time, the examples I see online for MVC basically make the Controller sound like an "event handler" and almost always relates to GUI actions (e.g. onClick, onEnter, onUpdate, etc).

An example of this is a GUI calculator where the View is the calculator, the Model contains all of the "business logic" (i.e. basic math), and the Controller simply handles when the user clicks on a button, updates the display, etc.

(Does anyone really "understand" OOP?! :queasy: There is so much bad info online...)

TomTees

NogDog

Well, in the web app world, all the client stuff is handled by the browser, and all we see on the server side is the resulting HTTP headers/data that the client sends us. So our "contoller" is mainly taking those inputs received via HTTP (i.e. mainly the stuff in $POST, $GET, and/or $_COOKIE) and deciding what to do with them. Whether deciding to return an error to the user and redisplay the form because the "password" and "repeat_password" fields do not match needs to involve a model or instead can be considered purely in the realm of the controller . . . well at that level of detail I don't care so much about theory versus what works. If I can use one line of code to validate that in my controller, do I really want to invoke something from some separate model class, even if theoretically that would somehow be more "correct"?

That being said, the more "logic" that can be moved into separate, narrowly focused classes and/or functions (whether we call them models, controllers, helpers, or whatever), the cleaner and more loosely coupled your application will be. If you want to just create a Customer data validation function somewhere and pump all the form inputs into it and maybe have it return an array of field-names => error-messages, I think that could be good modularization. Whether you save that validation function as a static method in a validator class and call it a "model" or save it as a procedural function in an include file and call it a "helper" doesn't really matter to me nearly as much as the decision to modularize it in some way in the first place.

Tom_Tees

NogDog;10955135 wrote:
Well, in the web app world, all the client stuff is handled by the browser, and all we see on the server side is the resulting HTTP headers/data that the client sends us. So our "contoller" is mainly taking those inputs received via HTTP (i.e. mainly the stuff in $POST, $GET, and/or $_COOKIE) and deciding what to do with them.

Okay.

Whether deciding to return an error to the user and redisplay the form because the "password" and "repeat_password" fields do not match needs to involve a model or instead can be considered purely in the realm of the controller . . . well at that level of detail I don't care so much about theory versus what works. If I can use one line of code to validate that in my controller, do I really want to invoke something from some separate model class, even if theoretically that would somehow be more "correct"?

Fair enough.

But let's say this is now later that it is checkout time and we need to calculate what shipping options are available or how much shipping costs or calculating volume discounts?

That is business logic, and so it should be in the Model, right?

That being said, the more "logic" that can be moved into separate, narrowly focused classes and/or functions (whether we call them models, controllers, helpers, or whatever), the cleaner and more loosely coupled your application will be. If you want to just create a Customer data validation function somewhere and pump all the form inputs into it and maybe have it return an array of field-names => error-messages, I think that could be good modularization. Whether you save that validation function as a static method in a validator class and call it a "model" or save it as a procedural function in an include file and call it a "helper" doesn't really matter to me nearly as much as the decision to modularize it in some way in the first place.

Okay, I would agree that smaller, more specialized classes are a big benefit of OOP.

Maybe I'm just too hung up on this classification of Model vs View vs Controller.

I suppose you could have intelligently designed classes and not use MVC or at least get hung up on whether a class is technically a "Model" or "Controller".

Of course I still want to know how MVC should be done!! 🙂

TomTees

NogDog

I guess the best way I can think of to describe it is that the controller defines the "flow" of the application. It decides what should be done next, and then causes it to happen. It bases those decisions initially on the inputs it receives from the views that trigger it, then may access certain models to help it decide what to do next and how to do it as well as to deal with the handling of the application data. Eventually it may generate output back to the user via one of those views, possibly sending some of the model data to that view.

I think that in a pure, ivory tower approach to MVC some things which most of us put into controllers would "correctly" be in a model, but from a practical standpoint it is not really necessary (and possibly counter-productive). Do I really need to call a model to determine that I need to calculate shipping costs now when processing a request to submit an order, or can I just go ahead and make that decision in-line within my controller code with a simple line or two of code instead of invoking some other object?