Модульность в mvc, как лучше реализовать?

Question

[Павел]

Разрабатываем систему на backbone.js + slim.php
Они оба поддерживают REST-запросы, используем подход формирования url-запросов для ajax с помощью "/"

GET "/users/45"  // вернет из базы юзера 
POST "/users/"  // создаст нового

Есть достаточно много информации по данным примерам, но все они простые. Как только мы сталкиваемся с реальными проектами (а не todo-шками), получаются проблемы.

Как быть, когда одна и та же сущность (например, user), встречаются внутри многих контейнеров, и при этом в зависимости от того, где мы подключаем сущность user, нам нужны определенные данные.
Вопрос номер 1
Создавать по модели на каждое представление? Например, user в комментарии отличается от user в списке друзей. Еще больше отличается от модели user на странице профиля -- там куда больше информации необходимо отобразить. Получается на каждую сущность по 20 моделей?
Вопрос номер 2
Как нам тогда в рамках /user/id системы подключать и выбирать те или иные данные на связке slim-backbone?
Получается, что на каждую сущность придется создавать уйму моделей, вьюх (ну без последних никуда).
Нормален ли подход такого формата:

• users/45 - получаем полную модель пользователя
  
• friends/users/45 - получаем обрезанную модель (имя, ссылка, url-картинки)
  
• reports/7/users - получаем коллекцию пользователей, который сделали отчет №7
  
• reports/7/users/45 - получаем модель данных пользователя №45, который сделал отчет №7
  
• reports/7/users/45/files - получаем коллекцию файлов, которые пользователь №45 прикрепил к отчету №7
  

Или выбрать 2-3 модели для каждой сущности (подробная, краткая версии) и выбирать их?
Что почитать можно по теме для построения архитектуры?

p.s.: после нескольких неудачных подобных заходов к проектированию, и потерянных недель в разработке с мертверожденных проектов появилась какая-то боязнь ошибиться.

Answer 1

[Сергей Протько]

Создавать по модели на каждое представление?

Модель в контексте MVC это не модель отдельных сущностей, а модель части системы (или всей системы), которая нужна для этой конкретной view. То есть представьте себе "модель" системы как нейкий объект, внутри которого есть другие объекты, которые работают с третьими и так далее. Такая вот иерархия. Так вот вьюшки выходит коннектятся каждая к своему кусочку этой иерархии, и по сути кроме этой точки соприкосновения ничего более о системе не знают. У них весьма ограниченное представление о системе и много знать им не надо.

Так вот. В REST "вьюшка" у вас - репрезентация ресурса. И они не должны (хоть и могут) быть проекцией таблиц в базе данных.

Получается на каждую сущность по 20 моделей?

Тут есть несколько подходов, основной из них - не париться и просто в рамках определенного ресурса подсовывать тот кусок данных сущности который нужен. Все же не пихать в json как-то что-то проще чем пытаться достать то чего нет.

Так же есть подход, описанный в стандарте jsonapi.org, где у вас есть дополнительные параметры в query string, которые позволяют "включать" определенные группы связанных ресурсов и т.д. Это дает нам определенную гибкость в плане работы с API но в случае например мобильных приложений есть свои нюансы.

появилась какая-то боязнь ошибиться.

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