Вопрос по MVC

Здесь в контроллере очень много работы делается. Я бы сделал так:

Код (PHP):

1. class reg_controller extends base_controller {
2.     
3.     function index() {
4.         $provider = new Authorization_Provider; // Фактически, модель, реализующая регистрацию/авторизацию
5.         try {
6.              $provider->register_user($_POST);
7.         }
8.         catch (Exception $e) {
9.             $this->view->load_view('failed'); // шаблон с сообщением что данные заполнены не верно
10.             return;
11.          }
12.         $view->load_view('success'); 
13.     }
14. }
15.  

Что внутри Authorization_Provider - это ещё подумать надо. Как-то не приходилось MVC с нуля выстраивать.

 

Ну тут разные варианты могут быть. Я бы не стал делать классы login_model, register_model - всё-таки они отражают, фактически, одно и то же понятие "Авторизация". Я да, склонен делать один контроллер для пользователя, в котором у меня будут собраны относящиеся к нему функции. Хотя я ещё недостаточно проникся принципами SOLID, вот осилю талмуд про UML, который сейчас читаю, прочитаю и про него книгу, может мнение переменится. А вот моделей он может использовать несколько. И внутри я склонен делать достаточно много связанных классов, просто по небольшому моему опыту, мне так удобнее отлаживать. К примеру, у вас login_model лезет в базу сам, а я бы создал что-нибудь типа User_Account_Repository, который бы искал по базе пользователей по разным параметрам. Идея не нова, конечно, это основываясь на том, что я сейчас читаю про архитектурные решения. Параллельно приходится работать, в том числе и с MVC, так что появляется удачный и неудачный опыт. К примеру, я пробовал в одном проекте на Kohana толстые контроллеры (лень было нормально спроектировать модели), код получился совершенно жуткий. В Open Cart, хотя мне в целом и нравится этот двиг, контроллеры просто жуткие (почитайте его код, если интересно). Они получив из модели данные, перегоняют их из одного массива в другой, сами обрабатывают. Короче, если нужно как-то расширить модель (к примеру, добавить новый вариант цены к продукту), приходится менять и контроллер, причём почти идентично.

 

Вы реально считаете, что несколько килобайт кода окажут значимый эффект на быстродействие? Я, когда разделяю систему на классы, забочусь только о том, чтоб это было логично. Вообще, насколько я понимаю всё, что я читаю про ООП, идти надо от сущности, которую пытаешься описать классом. Забивать в один класс всю систему - плохо, делать 1000 классов, у каждого из которых один-два метода - тоже плохо. И потом, если в классе только одна функция, нафига тогда этот класс дался? Можно написать просто функцию Мы же не на Java пишем, где всё должно быть инкапсулировано в классы, даже программа Hello, World. MVC - метод организации классов, но он не отменяет остальных принципов объектного проектирования

По поводу быстродействия - оно больше от алгоритма зависит. Вот вам пример из моей недавней практики. Проект на Kohana, магазин, там есть фильтры по производителям, заказчик захотел, чтоб рядом с каждым производителем в фильтре (а их там несколько сотен) была указано количество продуктов этого производителя. А в kohana есть такая штука ORM, позволяющая почти автоматом сгенерировать классы для таблиц и связей. Ну посему я написал что-то вроде этого:

Код (Text):

1.  
2. $vendors = ORM::factory("Vendor")->find_all(); // Теперь у нас в этой переменной массив производителей
3. foreach ($vendors as $vendor) {
4.    $count[$vendor->id] = $vendor->products->count_all();
5. }

Выглядит код очень красивым, да вот мой магазин на обычной загрузке страницы стал отжирать аж 30% ресурсов процессора! Тогда я вспомнил, что где-то читал про group by - запросы, и переписал этот код соответственно. Проблема была решена (нагрузка снизилась раз в 10, если не больше, сейчас у заказчика на одном сервере работает штук 10, наверное, магазинов на этом движке), и я заодно получил урок, что ORM не везде может быть так хорош.

Добавлено спустя 8 минут 54 секунды:
О, ещё свежий пример. Сейчас получил заказ на доработку сайта на Zend Framework, а его какой-то странный товарищ до меня писал. К примеру, создание постов там выделено в отдельный контроллер в модуле posts, под названием CreateController, зато акция удаления постов по какой-то причине оказалась в ReadController того же модуля, хотя, исходя из названия, он должен заниматься только отображением постов для чтения. Модели вообще ничего не делают, кроме общения с базой данных. Не знаю, мне активно такой подход не нравится. Так неудобно.