$object_cin = new CIO( );
$object_cin->invoke( $_POST[ 'model' ] );
class CIO
{
private function invoke( $model )
{
switch( $model )
{
case 'user_try':
$model = new MUserTry();
$this->send( $model->invoke( 1 ) );
break;
case 'user_new':
$model = new MUserNew( new IUniversals() , new IText(), new IMessage() );
$this->send( $model->invoke() );
break;
case 'user_exist':
$model = new MUserExist( new IUniversals() , new IText(), new IMessage() );
$this->send( $model->invoke() );
break;
case 'tweet':
$model = new MTweet( new IUniversals() , new IText(), new IMessage() );
$this->send( $model->invoke() );
break;
default:
echo "Incorrect Ajax Type provided";
}
}
private function send( $string )
{
echo "|P|" . $string;
}
}
Of course it will grow, and become impossible to maintain.
First of all, what is with the generic Control class? A website is supposed to have multiple controllers (I am assuming that it is somehow related to MVC, because that's where the term "controller" comes from), usually 1 controller per one "page" (granularity may change, depending on architectural pattern).
Next problem is the big switch statement. Each of the case's there should be a separate method in a controller. You end up repeating parts of code, just because of the design mistake.
You've run straight into the Fat Controller antipattern.
A controller is meant to be little more than glue logic. It passes the data from the request (GET, POST, WHATEVER) to whatever model knows how to handle it, formats whatever result the model returns and assigns it to the view to render.
At least that's what's supposed to happen.
Far too often, the developer fills the controller with the application logic, leaving the models as little more than CRUD objects for doing database access. This is not the way to develop an MVC application. Models are supposed to be "domain experts". As well as storing the data the application is working with, they are also meant to know what that data means, what is valid behaviour for given sets of data, and so on. This makes the model reusable, loosely coupled and highly coherent. You can use a rich model with many different view/controller combinations without difficultly.
If the application logic is in the controller, then you're stuck using that controller to execute the application logic, or even worse, you'll end up copying and pasting the same code into different controllers.
If the controller is full of application logic, then that's a sure sign that you need to rethink your design and refactor
Related
Using MVC I have something like this:
class Controller
{
//returns View
function indexAction()
{
$data = $this->getData($this->id);
$view = new ViewModel();
$view->setVariable('data' => $data);
//used to render HTML template + data above later on
return $view;
}
//gets data from DB
//currently also does business-proprietary computation on data
function getData($id)
{
//repository/dao pattern
$data = $this->repository->getData($id);
//Business Logic "derivation"
foreach ($data as $datum)
{
//that does not go into "Controller
//that does not go into "Repository"
//but where does it go? - that's my question
$derivedData[] = (new Business())->doLogic($datum);
}
return $derivedData;
}
}
Recap
I used Controller to get my data out of DB using Repository pattern, then placed received data into view. But business-related computations are left stranded.
Question
Where do I place my business logic computations that act on the data gotten from repository? The derived data which is to return to Controller later, to be placed into View?
My personal choices of architecture are usually to:
Have small controllers as thin as I can, doing only session and general right checking
Services that are handling all business logic, one (one classe yes) per potential feature I need
Services are querying repositories, and eventually manipulate the data in and out, but usually no Controller, nor view will do a ->save() anywhere.
This means that those services are usually designed to be independent from the database and easier to be tested because they only take care of one and only one task.
In your example, the whole function getData will be a service that I would call GetCarDataById. This assuming that you manipulate Cars, I don't like to leave data wandering alone.
EDIT: to make it clear, this kind of approach is not MVC to some definition, most people interpret MVC as putting all code either in controller, either in repositories (model). To others view, MVC doesn't mean that you have other classes, what I call services, and actually most of my code lives here.
The MVC pattern is clear for me.
From wikipedia:
The model directly manages the data, logic and rules of the
application. A view can be any output representation of information,
such as a chart or a diagram. Multiple views of the same information
are possible, such as a bar chart for management and a tabular view
for accountants. The third part, the controller, accepts input and
converts it to commands for the model or view.
Answering your question. The modifications goes in the model domain.
I have been developing a Sports Management website with user, roster, and schedule management using PHP and JS. This app has about 15 database tables to work with altogether. Recently I learned I was doing something majorly wrong: I was using individual PHP scripts as their own "apps".
Example: Individual scripts app
JS
var params = {
action : 'addGame',
date : 'someday',
hometeam : 1,
awayteam : 2
}
$.post('/php/scheduler.php', params);
PHP
class Scheduler extends TableManager{
public function addGame($date, $hometeam, $awayteam){
// do sql stuff
}
public function doAction($request){
switch($request){
case "addGame":
return $this->addGame($_REQUEST['date'], $_REQUEST['hometeam'], $_REQUEST['awayteam'];
break;
}
}
}
if(isset($_REQUEST['action'])){
$scheduler = new Scheduler();
$scheduler->doAction($_REQUEST['action']);
}
I learned that writing a proper PHP application means there should be a single "app" where all requests are routed. This is fine and I've done this - but now I face unknown territory. If I have 15 tables, and they all have a few very specific functions (they all extend TableManager to provide basic table functions, but some are obviously more specific) how can I write a request processor in my main App that handles requests for every table, without getting insanely complex?
Example: Single entry point app
JS
var params = {
action : 'addGame',
table : 'scheduler',
date : 'someday',
hometeam : 1,
awayteam : 2
}
$.post('/php/app.php', params);
PHP
class App {
private $scheduleTable;
public function createTable($name){
switch($name){
case "scheduler":
$this->scheduleTable = new Scheduler();
break;
}
}
public doAction($request){
switch($request){
case "addGame":
$this->createTable('scheduler');
return $this->scheduleTable->addGame($_REQUEST['date'], $_REQUEST['hometeam'], $_REQUEST['awayteam'];
break;
}
}
}
if(isset($_REQUEST['action'])){
$app = new App();
$app ->doAction($_REQUEST['action']);
}
Now I need to start using complex and bloated switch statements, as my tables all inherit TableManager and thus do many of the same actions, but also have unique functions. I'll need to switch on the incoming action, and then switch on the table. Not to mention all of the other features that this App will have (user system, for one). Is the only answer to write a massive switch statement?
From what I understand of your current predicament, yes. You could always use a PHP framework (Google them, there are many) but if you want to use your existing structure then of course you need a switch statement or a way to load the correct models for the page.
Note that you could always use something like this:
<?php
// I assume $request is sanitized.
// Check to see if the class file exists.
if( file_exists( 'class-directory/' . $request . '.inc.php' ) ) {
$class_name = ucfirst( $request );
$this->scheduleTable = new $class_name;
} else {
// Show error page, the request is not valid.
}
?>
Important note: for more security you should use $_POST, $_GET and $_COOKIE instead of $_REQUEST.
I have been reading up on DDD a lot over the last few days and could not find one solid example of how someone would go about simply registering a user on their site so after lots of reading I have stuck this together and I would like your feedback on it because I am sure it is far from perfect, it might even be completely wrong but here it goes:
RegisterController
$userMapper = $this->dataMapperFactory->build('user');
if($userMapper->fetchByUsername($username) !== NULL) {
// Error: The chosen username already exists
}
else {
if($userMapper->fetchByEmail($email) !== NULL) {
// Error: The email address already exists
}
else {
$userDO = $this->domainObjectFactory->build('user');
// Set the properties of the $userDO object here with the ones
// from the registration form
// Insert the new user into the database
$userMapper->save($userDO);
}
}
I have done all the form validation with my own FormValidation class so when I add the properties to the $userDO object they are all 100% ready to be inserted into the database (correct length, type, format, ranges etc) so how does the code look to you?
I think I am on the right track and I would really appreciate any tips on how to improve my code.
Also, the way I am checking if the username they chose has already been taken, is there a better way to do that? Instead of having to create an object each time to check? Like the old way I used to do it with a simple:
SELECt COUNT(*) FROM users WHERE username = 'john'
Thanks.
Some theory-related "blah":
As you might be aware, the core concept of MVC and MVC-inspired design patterns is the SoC. It dictates that you divide these patterns in to major layers: presentation layer and domain model layer.
In this case it is significant, because you current structure of controller contains application logic (the interaction domain logic entities and storage abstractions), whereas a controller should be only responsible for altering state of model layer (and sometimes - the current view) based on user input.
You end up violating bot the above mentioned SoC and also SRP.
Note: in context of web based MVC variations the "user" is a web browser, not the person sitting behind it.
Instead you should encapsulate the application logic in services (as #Gordon mentioned). In a fully realized model layer the different services become something like a public-ish API through which the presentation layer interacts with model.
Though, unlink Gordon, I would recommend your service to be a bit broader. In case of user registration, I would make it a part of CommunityService or maybe MembershipService. A structure that handles all the aspects of the user account management as far as the model layer is concerned.
The code bits:
One way for using in controller would look something like:
public function postUser( $request )
{
$community = $this->serviceFactory->build('Community');
$community->addUser( $request->getParameter('username'),
$request->getParameter('password'),
$request->getParameter('repeated_password'),
$request->getParameter('email') );
}
While this is a valid way, you might already notice an possible problem. Even when user registration need only the minimum of data, the amount of parameters that you end up passing to the service makes it hard to use.
Passing the $request on to service is not a valid improvement. You would just end up violating Law of Demeter. Instead i would recommend something like:
$keys = ['username', 'password', 'repeated_password', 'email'];
$community->addUser( $request->getParameters( $keys ) );
Where the getParameters() method is implemented similar to:
public function getParameters( $keys )
{
$response = [];
foreach( $keys as $parameter )
{
$response[ $parameter ] = $this->getParameter( $parameter );
}
return $response;
}
Domain logic and validation
You mentioned, that some FormValidation class, that you are using to make sure, that your instance of User domain object receives proper values. Actually the data validation is one of the domain object's responsibilities. You still might use a separate validation class, to avoid code duplication, but that would be a dependency, which is injected by domain object's factory to share between instances.
Note: in my personal experience, the duplication for validation is quite rare for anything but the null-checks. Each of complicated validation rule-sets are targeted at fields of one specific domain object. That, in my opinion, makes a validation class quite redundant ... unless you expect to share same validation class between multiple projects.
The code-flow usually is such that, when you need to store the data from domain object, you check if it has not acquired an error state, and if there is an error, you actually dump it in session, for a retrieval after redirect.
if ( $user->isValid() )
{
$sqlMapper->store( $user );
}
else
{
$sessionMapper->storeUser();
}
In this use-case pre-validated input ends up actually being harmful.
Everyone understands mvc as he wills, but sometimes I do not, at all.
Currently the majority of my controllers look like this:
<?php
$input = $_REQUEST['field']
$model = new Model();
$status = $model->launchSpaceShuttle($input);
switch($status)
{
case Model::STATUS_LAUNCHED:
header('Location: Mars');
break;
case Model::STATUS_INVALID_INPUT:
echo "Please press the big red button correctly";
break;
case Model::STATUS_PILOT_IN_HANGOVER:
...
...
case etc.
}
This leads to the obvious question:
Is this how it's supposed to be? Model's returning status codes and controllers deciding how to display and what?
Because this very much conflicts with the theory about simple, short controllers that act as a really thin wrapper between the input device and the model.
bonus case: what about ajax requests if I'm too lazy to create a view ;
Ah, that's easy. Just move the entire switch to a view file.
It's the view's responsibility to interact back with the user.
Redirecting from inside the view is just as fine.
Anyway in most frameworks the view file inherits the $this variable which represents the active controller.
Same regarding ajax requests.
In a MVC pattern, what's the best way to handle when a single view could have multiple actions of the same type (e.g POST)?
Say for instance in a TODO list application. You might allow a user to create multiple lists. Each list could have multiple items. So a user navigates to site.com/list/1 which shows them all the items on the 1st list (1 is a GET parameter). There are then 2 forms (POST) on this page to allow a user to:
Create a new item
Delete an existing item
Should the bootstrap create a "listcontroller", inspect the POST variables and then call the appropriate method similar to :
$lc = new ListController();
if(strtolower($request->verb) === 'post'):
if(isset($_POST['title'])) :
$data = $lc->newItem($_POST);
$load->view('newitem.php', $data);
else if(isset($_POST['delete']) && isset($_POST['id'])):
$data = $lc->deleteItem($_POST);
$load-view('deleteitem.php', $data);
endif;// End if post title
else:
//GET request here so show view for single list
endif; //
Or is it better to just do something like
$lc = new ListController();
if(isset($_POST)):
//controller handles logic about what function to call
$data = $lc->PostAction($_POST);
// $data could also potentially hold correct view name based on post
$load->view();
else:
//again just show single list
endif;
I'm just struggling how best to have a controller potentially handle multiple different actions, as there's potentially quite a few nested if/else or case statements to handle different scenarios. I know these would have to sit somewhere, but where is cleanest?
I know that there are many frameworks out there, but I'm going through the whole "want to understand best practice" behind it phase. Or is this totally the wrong way to do it? Should the controllers actually be structured differently?
To begin with, I actually really like, how you are dealing with implementation of MVC. None of that rails-like parody, where view is managed inside the controller.
Here is what I think is the root of your problem: you are still using a "dumb view" approach.
View is not supposed to be a synonym for "template". Instead it should be a full object, which has knowledge-of and ability-to deal with multiple templates. Also, in most of MVC-inspired design patterns, the view instances are able to request information from model layer.
In your code the issue can be traced back to view's factory ( the $load->view() method ), which only gets what controller sends it. Instead controller should only change the name of the view, and maybe send something that would change the state of view.
The best solution for you would be to create full-blown view implementation. Such that view itself could request data from model layer and , based on data it received, decide which template(s) to use and whether to require additional information from model layer.
I think you're somewhat on the right track with the latter approach. However, you should not hard code the calling of actions in your bootstrap. The bootstrap should interpret the URL and call the action methods dynamically through the use of a function like call_user_func_array.
Also, I would suggest that you leave the rendering of views up to the action code so the action logic is self sufficient and flexible. That would allow the action to analyse the input for correctness and render errors or views appropriately. Also, you've got the method 'deleteItem' on your controller, but that should really be the work of a model. Perhaps you should read up some more on MVC and try to work with an existing framework to understand the concepts better before you try to implement your own framework (I would suggest the Yii framework for that).
Here's an example of how I think your logic should be implemented in a good MVC framework.
class ListController extends BaseController
{
public function CreateAction($title){
if(ctype_alnum($title))
{
$list = new List();
$list->Title = $title;
if($list->insert())
{
$this->render_view('list/create_successful');
}
else
{
$this->render_view('list/create_failed');
}
}
else
{
$this->render_view('list/invalid_title');
}
}
public function DeleteAction($id){
$list = List::model()->getById($id);
if($list == null)
{
$this->render_view('list/errors/list_not_found');
}
elseif($list->delete())
{
$this->render_view('list/delete_successful');
}
else
{
$this->render_view('list/delete_failed');
}
}
}
here is a great tutorial on how to write your own MVC framework