Проблема с дизайном базы данных для MVC - 1 таблица на модель

Question

Самое большое препятствие для начала работы с инфраструктурой MVC связано с концепцией таблицы от 1 до 1 БД. Для меня это слишком упрощенно и нереально для всего, кроме простого приложения. Тем не менее, MVC используется повсюду, включая этот потрясающий сайт StackOverflow. Как обычно, все примеры кода и учебные пособия, с которыми я сталкиваюсь, очень просты, и отношения 1 к 1 в этих случаях работают нормально. Но то, что я ищу, это твердый реальный пример модели MVC, которая объединяет таблицы адресов. В случае стекового потока я представлял бы дизайн БД с таблицами, такими как Вопросы, Теги, Пользователи и т. Д. В моем дизайне БД у меня может быть таблица ссылок Question_Tag для поиска всех тегов, связанных с данным вопросом. Как MVC справляется с этим?

Answer 1

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

Это всего лишь стратегия, которую взяли на вооружение некоторые популярные фреймворки (Ruby on Rails - может быть, и ASP.NET MVC?) Для удобства. Но это не требование MVC. Spring MVC (для мира Java) не имеет понятия о том, как сопоставить компоненты модели с базой данных, на самом деле его прелесть в том, что ему все равно - вам просто нужно предоставить данные модели для использования, и где вы получите это из среды MVC не волнует.

Другими словами, вам не нужно предполагать, что шаблон MVC означает, что вы должны использовать одну таблицу базы данных на компонент модели. Черт возьми, вам даже не нужно использовать базу данных, ваша модель также может быть получена из простого файла или веб-сервисов (и что хорошо в MVC, это то, что если вы спроектируете свое приложение должным образом, вы можете поменять различные реализации уровня данных из вашего приложения и View или Controller даже не узнает ).

Answer 2

Я думаю, вы путаете MVC с ORM. ORMS связывают вас один на один с помощью таблиц и объектов базы данных.

Что вам нужно сделать, это отправить объекты Model из MVC на уровень DAL, который может заполнить их для вас из запросов SQL и вернуть вам объекты. Аналогичным образом вы можете отправить заполненные объекты с изменениями обратно в слой DAL для сохранения.

Это гораздо более чистый и гибкий дизайн, который вы можете использовать с шаблоном MVC, и вам не нужно связывать свои объекты с таблицами базы данных при использовании возможностей объединения SQL.

Answer 3

ОК, Ахмад, в этом есть смысл. Но во всех примерах MVC, которые я видел, модель представляет собой нечто вроде комбинированного BLL / DAL. То, о чем вы говорите, - это сохранение модели как чистого BLL и создание отдельного DAL. Я думал, что одной из основных особенностей использования существующего фреймворка mvc является ускорение разработки. Если мне нужно будет создать DAL поверх MVC, я могу также придерживаться моего существующего процесса разработки вне MVC создания страниц с отдельными уровнями бизнес-логики и доступа к данным.