Архитектура MVC. Что в модели? - PullRequest
2 голосов
/ 15 июля 2009

Я новичок в MVC, но уже вижу его преимущества и преимущества. Тем не менее, у меня есть (вероятно, легко ответить) вопрос о дизайне:

Я думал о моделях и обдумывал, как правильно их структурировать. На мой взгляд, есть несколько вариантов:

1) Модели и структура таблиц имеют отношение 1 к 1 ... это означает, что в значительной степени для каждой таблицы существует соответствующая модель. Класс модели имеет атрибуты, соответствующие столбцам таблицы, и имеет любые необходимые методы (например, методы получения и установки) для манипулирования данными в таблице любым необходимым способом. Это похоже на универсальную опцию, и я думаю, что тогда я бы заставил контроллер вызывать модели по мере необходимости для выполнения любой бизнес-функции.

2) Модели более тесно связаны с работой бизнес-логики, а не с данными: так, например, если на внешнем интерфейсе удаление определенного объекта затрагивает несколько таблиц, модель затем «моделирует» это поведение и взаимодействует с несколькими таблицами и выполняет необходимую функцию. Затем контроллеру просто нужно вызвать единственную модель для любого делового поведения. Это менее общий характер, поскольку модели гораздо более тесно связаны между собой, но, кажется, быстрее реализуются.

3) Что-то среднее между первыми 2 вариантами. Или, может быть, я полностью упускаю суть.

Надеюсь, это имеет смысл! Если я не совсем упускаю суть, я склонен думать, что вариант (1) лучше. Есть идеи?

Редактировать: Не то чтобы это имело значение, но я планирую использовать Codeigniter PHP MVC framework.

Ответы [ 5 ]

5 голосов
/ 15 июля 2009

Оба являются допустимыми реализациями и, в зависимости от ваших потребностей, могут хорошо работать.

Ваш # 1 по сути описывает шаблон Active Record , который используется SubSonic, Castle и множеством других реализаций ORM.

Ваш # 2 по существу описывает подход Entity Framework / Hibernate / LightSpeed, где вы имеете дело с объектами, которые более концептуально связаны с вашим доменом, а не с таблицами. Вместо ваших объектов, содержащих свойства идентификатора внешнего ключа, они фактически содержат ссылки на другие доменные объекты, которые затем создаются при доступе.

Оба пути великолепны. Подход Active Record обычно более интуитивен для новичков и потенциально имеет меньше подводных камней. EF-стиль может сэкономить много кода базового уровня и работать с FK непосредственно в коде.

Редактировать: Для ясности, в обеих ситуациях вы описываете уровень доступа к данным, а не только модель. Однако на самом деле вы довольно близки, так как большинство моделей просто представляют один или несколько объектов такого типа.

1 голос
/ 15 июля 2009

Все вышеперечисленное.

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

0 голосов
/ 15 июля 2009

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

0 голосов
/ 15 июля 2009

Думайте о базе данных как о модели, о бизнес-логике как о контроллере и о пользовательском интерфейсе как о представлении. Это может помочь. Это слишком упрощенный подход к вещам, но он дает правильное разделение данных и поведения.

0 голосов
/ 15 июля 2009

Номер 1 - это путь. Вариант 2 действительно работа контроллера. Например, контроллер затем берет модели и выполняет над ними действия и передает результаты в представление.

Думайте об этом так:

Модель = ваши данные

Контроллер = бизнес-логика

Просмотр = отображение данных и действий

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...