Что такое Model в МVС?

Question

[StanGrin]

Что такое Model в MVC ? это модель представления например RegistrationViewModel которая является POCO и содержит данные необходимые для отображения страницы( шаблонизатора )? Или это модель бизнес логики например User? Как вы понимаете модель в mvc?

Answer 1

[Антон Натаров]

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

В целом, модели

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

Best Практик из Yii2

Comments

[StanGrin]

Антон Натаров могут содержать атрибуты для представления бизнес-данных; могут содержать методы с реализацией бизнес-логики; а как же принцип единственной обязанности ?

[Никита]

StanGrin: ничто не мешает вам сделать 2 модели со своими обязанностями. Часто встречаемые это провайдеры, голые модели и модели с б-логикой.

[Антон Натаров]

StanGrin: а он и не нарушен. К тому же, принцип это не табу, а напутствие, он распространяется не только на класс, но и модуль, приложение. К тому же этот принцип распространяется только на компилируемые языки(ИМХО) И зависит от плоскости применения. Конечно можно разбить сложные вещи на еще часть классов, это зависит от фреймворка с которым вы работаете и в целом вашего подхода(Но не стоит простое приложение - делать более сложным, потому что так пишут в книгах). Если от вас потребуется какое-то высокоуровневое обеспечение хранения данных, то вы поправите один класс, если косяки с запросами то другой. И тут встает такая дилемма, например в Yii2(сущность, запросы, получаемые атрибуты и иногда валидация, хранятся в классе модели). в случае с Symfony и Laravel (Entity и магические методы в одном классе, запросы - в другом). Таким образом вы разбиваете на слой доступа DAL.

[StanGrin]

Никита тогда что такое модель в mvc и какова ее обязанность?

[StanGrin]

Антон Натаров "Но не стоит простое приложение - делать более сложным, потому что так пишут в книгах." Мне кажется что в книгах как раз пишут как из сложного, жестко связанного и не понятного кода сделать простой и легко поддерживаемый код. разве нет?

[Антон Натаров]

StanGrin: Чтобы не делать жесткой связанности достаточно придерживаться Depencdency Injection, IoC, или ServiceLocator на крайняк. Не все одинаково полезно, короче говоря.

[StanGrin]

Антон Натаров Но Depencdency Injection и подразумевает следованию принципу единственной обязанности, каждый класс делает что-то одно и делает это хорошо (одна причина для изменения). А вы предлагаете что модели в слое представления mvc могут содержать атрибуты для представления бизнес-данных и могут содержать методы с реализацией бизнес-логики. Вы потом этот объект отдаете представлению?

[Антон Натаров]

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

Answer 2

[Толстый Лорри]

В MVC модель - это как раз доменная сущность, с которой работает бизнес-логика (тоже относящаяся к части "Model"). Если же у вас есть необходимость как-то трансформировать/дополнять модель для передачи во View, то здесь и применяют т.н. ViewModels, на которые маппятся сущности.

MVC - это масштабируемый паттерн. Допустим, решение состоит из проектов:

• содержащего доменные сущности и бизнес-логику
  
• слой доступа к данным (DAL), который управляет хранением и передачей сущностей
  
• web-интерфейс (ASP.NET MVC-приложение)
  

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

Comments

[Толстый Лорри]

StanGrin: В контексте именно веб-приложения вью-модель может быть вполне-себе моделью. А его бизнес-логика будет состоять, скажем, из репозитория, который будет маппить DTO в местную вью-модель (которую будет получать ничего не знающий ни о каких DTO или доменных сущностях контроллер).

[StanGrin]

Толстый Лорри получается что mvc это vmvc =). контроллер должен получать DTO маппить на ViewModel и отдавать во View ?

Answer 3

[Александр Макаров]

M в MVC — это доменная-модель. То есть набор классов, отвечающий за логику приложения.

Comments

[StanGrin]

Александр Макаров а если понадобится еще один слой отображения данных (например rest api для мобильного приложения) то нужно будет копировать всю доменную модель в новый проект или использовать первый как собсвенно сам домен?

[Александр Макаров]

StanGrin: можно взять структуру по типу advanced. Там есть common, классы в котором доступны и там и там.

[StanGrin]

Александр Макаров что такое структура по типу advanced ?

[Александр Макаров]

StanGrin: https://github.com/yiisoft/yii2-app-advanced

[Александр Макаров]

Это если мы про Yii говорим. А так ничего не мешает добавить ещё один рут для классов через автолодер по PSR-4.

[StanGrin]

Александр Макаров в папке common/models/ лежит и User и LoginForm этож каша будет когда проект будет большой? если еще будет класс post и нужно будет получить все посты юзера, куда писать метод getPostsbyUser в юзер или пост? и это только две сущности а что если их будет много, то не понятно где искать нужный запрос если сам не писал его... мне кажется такой подход прививает писать код с душком изначально.

[Александр Макаров]

Будет каша — разложите как удобнее. Не обязательно всё пихать в один namespace. getPostsbyUser надо, по-хорошему, писать в PostRepository.

[StanGrin]

"надо, по-хорошему, писать в PostRepository" а почему сразу так не сделать ведь это будет проще и понятнее

[Александр Макаров]

StanGrin: потому что 80% проектов вообще CRUD и там репозиторий будет излишеством.

Answer 4

[saltydogd]

Бизнес логика все же выводится в контроллер, модель как правило соответствует объекту из предметной области (то что необходимо отображать/хранить), и дополнять ее расширенной логикой - ну не совсем этично (максимум хелперы какие-то да валидаторы)

Comments

[Антон Натаров]

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

[StanGrin]

Антон Натаров а разве не нужно выносить работу с бд вообще в отдельный слой?

[Никита]

Логика в контроллере - миф, которым пользуются недоучки, хотяб в вики гляньте определение MVC.

[Антон Натаров]

StanGrin: зависит от ситуаций и архитектуры. И мне кажется вы путаете немного абстракции. Работу с бд(подключение и конфигурации) и работа маппера(создание объектов на основании таблиц в БД и классов моделей)

Если это большое приложение, то да - выносить. Если у вас модель и у нее всего два три запроса (findOne, findAll, findCustom) - то стоит ли ради этих трех запросов городить отдельный слой ?

[StanGrin]

Антон Натаров городить его не стоит а вот вынести работу с бд в отдельный слой думаю стоит, имхо это не усложнит проект а наоборот разрулит его ))) у вас всегда есть 100% уверенность что маленький проект не станет большим или в нем не будет координальных изменений?

[Антон Натаров]

StanGrin: чаще всего да, человек приходит и делает заказ на 2000$ и я понимаю, что от меня потребуется текущие + сверху мелкие фичи(которые не затрагивают основу). Или человек приходит и просит корпоративный проект за 10к и то и другое тестируется, спокойно расширяется стандартными средствами фрейма. И даже если пришел проект на доработку или апгрейд, который требует перепланировки(а тут учитывается преще переписать по новой или переделать текущее). Вынести в отдельный слой не такая большая задача, которая потребует больших ресурсов и времени компании.

Answer 5

[trevoga_su]

www.phpinfo.su/articles/theory/model_view_controll...