ЛУЧШИЙ СПОСОБ #PHP MVC [закрыто]

A Controller - это связующее звено между вашей бизнес-логикой и выполненными запросами. Хотя он может содержать довольно много функций, все они должны быть специфичными для рассматриваемого целевого запроса.

Небольшое описание контроллера, вы найдете похожие случаи:

Контроллеры - это клей, который связывает модели, представления и другие компоненты вместе в работоспособное приложение. Контроллеры отвечают за непосредственное отношение к запросам конечных пользователей. Таким образом, контроллеры

Понимая, что для того, чтобы ваши контроллеры были сосредоточены, вам нужно задать себе вопрос: передается ли эта функция контроллеру? ] способ организации их MVC. Вы заметите, что они разделили все authentication запросов в AuthController.

Этот AuthController отвечает за:

-> захват запроса POST, который будет содержать пароль и электронную почту (или любой другой метод, который вы создали).

-> Аутентифицировать пользователя в случае успеха; -> перенаправить на правильные представления в зависимости от результатов для auth (вернуться на страницу входа или показать панель мониторинга);

Самое позднее - это то, где вы должны начать организовывать свой поток. Проверьте это:

-> Если пользователь был успешно аутентифицирован, то вы хотите представить представление dashboard;

-> представление панели мониторинга на самом деле не является частью AuthController более непосредственно связан с DashboardController. Итак, вы на самом деле захотите перенаправить с AuthController на DashboardController через routes;

Так что ответ на ваш вопрос, это зависит! Если логика, которую вы добавляете в свой контроллер, фокусируется на определенном секторе бизнес-логики вашего приложения, не беспокойтесь о количестве methods, которое у вас может быть. Все это действительно зависит от сложности вашего приложения;

НО , если ваш контроллер начинает использовать методы, которые делают много разных вещей для разных секторов вашего приложения, допустим, у вас есть контроллер, который :

->creates products
->deletes products;
->Authenticates users;
->list users;
-> etc

Тогда вы делаете это неправильно и не разделяете бизнес-логику соответствующим образом.

Ответственность контроллера состоит в том, чтобы склеить запрос с правильной бизнес-логикой, а затем перенаправить все данные в правильное представление для их отображения. Он не должен знать о:

-> How the data is fetched (doing the Model job);
-> How the data should be parsed for display (doing the Marshaller job);
-> Checking if the data exists (doing the Hydrator job);
 among other concerns. It literally does:


1. Oh! got a request from route `list/users`;
2. To list users I better call all users in my database (Call the Model);
3. Right, I believe they should be here, lets tell the view to be generated;
4. Here you go view, you list them as you wish, I dont really care;

Надеюсь, это поможет!