php oop MVC design - правильная архитектура для приложения для редактирования данных

Question

Теперь, когда я прочитал огромное количество постов, статей, вопросов и ответов по ООП, MVC и шаблонам проектирования, у меня все еще остаются вопросы о том, как лучше всего построить то, что я хочу построить.

Мой маленький фреймворк построен в стиле MVC.Он использует smarty в качестве средства просмотра, и у меня есть класс, настроенный в качестве контроллера, который вызывается из URL.

Теперь, где я думаю, что я заблудился, это часть модели.Я мог бы смешивать модели и классы / объекты со многими (или маленькими). ​​

В любом случае, пример.Когда цель состоит в том, чтобы получить список пользователей, которые находятся в моей базе данных:

, приложение вызывается, например, «пользователи / список». Затем контроллер запускает список функций, который открывает экземпляр класса «пользователь»."и просит этот класс получить список из таблицы.вернувшись к контроллеру, контроллер передает его зрителю, присваивая результирующий набор (массив) шаблону и устанавливая шаблон.Затем пользователь щелкает строку в таблице, которая скажет контроллеру, например, запустить «пользователь / редактировать», что в свою очередь создаст форму и заполнит ее пользовательскими данными для редактирования.

пока все хорошо.

сейчас у меня все это объединено в одном пользовательском классе - так что в этом классе есть функция create, getMeAListOfUsers, update и т. Д., А также такие свойства, как hairType и noseSize.Но при правильном дизайне я бы хотел отделить «пользователя» (со свойствами, такими как, имя пользователя, большой нос, вьющиеся волосы) от «getme a список пользователей», который бы больше походил на «класс менеджера пользователей».

Если бы я реализовал класс менеджера пользователей, как бы он тогда выглядел?должен ли он быть объектом (на самом деле не может сравнивать его с вещами реального мира) или это должен быть класс с просто открытыми функциями, чтобы он более или менее выглядел как набор функций.массив найденных записей (например: array([0]=>array("firstname"=>"dirk", "lastname"=>"diggler")) или он должен возвращать массив объектов.

Все это все еще немного сбивает меня с толку, и мне интересно, может ли кто-нибудь дать мне немного понимания того, каклучше всего подойти к этому.

Answer 1

Уровень абстракции, необходимый для обработки и данных ( Business Logic ), зависит от ваших потребностей.Например, для приложения с Transaction Scripts (что, вероятно, имеет место с вашим дизайном), класс, который вы описываете, который выбирает и обновляет данные из базы данных, звучит для меня верным.

Вы можете обобщить вещи немного больше, используя Шлюз табличных данных , Шлюз данных строк или Active Record even.

Если вы чувствуете, что затем дублируете много кода в своих скриптах транзакций, вы можете создать свой собственный Модель домена с Data Mapper .Тем не менее, я бы не стал слепо делать это с самого начала, потому что для этого нужно гораздо больше кода.Также не стоит писать Data Mapper самостоятельно, но использовать для этого существующий компонент. Doctrine - это такой компонент в PHP.

Другой существующий компонент ORM (Object Relational Mapper) - это Propel , который обеспечивает Active Records .

Если вы просто ищете быстрый способ запроса базы данных, вы можете найти NotORM вдохновляющим.

---

Вы можете найти шаблоны, перечисленные в курсив в

• http://martinfowler.com/eaaCatalog/index.html

, в котором перечислены все шаблоны в книге Шаблоны архитектуры корпоративных приложений .

Answer 2

Еще одна альтернатива Doctrine и Propel - PHP Activerecords .

Doctrine и Propel - действительно могучие звери.Если вы делаете небольшой проект, я думаю, что вам лучше с чем-то более легким.

Кроме того, когда речь идет о сторонних решениях, существует множество сред MVC для PHP, таких как: Kohana, Codeigniter, CakePHPZend (конечно) ...

Все они имеют свои собственные реализации ORM, обычно более легкие альтернативы.

Для фреймворка Kohana также существует Auto modeler , который предположительноочень легкий.

Лично я использую Doctrine, но это огромный проект.Если бы я занимался чем-то меньшим, я бы скорее выбрал более легкую альтернативу.

Answer 3

Я не эксперт в этом, но недавно сделал почти то же самое. Я настроил его так, что у меня есть один класс для нескольких строк (Users) и один класс для одной строки (User). «Класс нескольких строк» ​​- это просто набор (статических) функций, и они используются для извлечения строк из таблицы, например:

$fiveLatestUsers = Users::getByDate(5);

И это возвращает массив объектов User. Каждый объект User затем имеет методы для извлечения полей в таблице (например, $user->getUsername() или $user->getEmail() и т. Д.). Я имел обыкновение просто возвращать ассоциативный массив, но затем вы сталкиваетесь со случаями, когда вы хотите изменить данные, прежде чем они будут возвращены, и именно здесь наличие класса с методами для каждого поля имеет большой смысл. *

Редактировать: User объект также имеет методы для обновления и удаления текущей строки;

$user->setUsername('Gandalf');
$user->save();
$user->delete();