Я понимаю что это были не Вы).
Тут проблема терминологии. Я понимаю под моделью все что сохраняет состояние и может быть использовано для абстрактного моделирования приложения, а не то что наследуется от класса/структуры Model/CModel/TypeModel/ActiveRecord::Base и какие там еще бывают Model и AR.
Если Вы используете отдельный слой для бизнес-логики, а не пишете ее в контроллерах, то Вы по всем советам из статьи поступаете правильно. Сервис тоже может быть моделью. Вопрос терминологии, не более.
github.com/jinzhu/gorm тут лежит прекрасный ORM для Golang, который похож на Ваш подход, но это только в контексте ORM, а не фреймворка.
Лично мне всегда был ближе подход user.login() чем userService.login(&user);
Вы когда-нибудь пробовали писать тесты для контроллера? Или может Вы можете легко инстанцировать контроллер вне приложения, без запуска всего MVC стека, перехватчиков запросов и помощников действий? Я пробовал. Это ад. Контроллеры зависимы от своих приложений и фреймворков на которых они написаны — модели нет. Вы пытались писать сервисы, где надо будет уверенным в корректности передаваемых данных? Неужели свою проверку данных сделать легче чем использовать магию моделей? Сколько языков и фреймворков Вы попробовали? C# и ASP .NET? Кто-то ковырял Revel(golang), Play/Spring(Java), Yii/Kohana/Laravel/Zend(PHP), Rails(Ruby)? Я уже не говорю про миллионы фреймворков для JS. Из одного туториала и примеров использования одного фреймворка делаем выводы по всему паттерну и игнорируем кучи трудов в интернете и на бумаге? Ооок, минусуйте дальше.
Я вот, например, использую ViewModel в проектах ASP.NET MVC.
Либо Вы мешаете два паттерна, либо используете MVVM.
В любом случае, как я уже сказал, VM и M нельзя сравнивать, это разные вещи.
А это противоречит вашему подходу: вы из контроллера передаете полную модель данных, а я только те данные, которые будут нужны представлению.
Я такого не говорил. Я передаю из контроллера то что контроллер может передать и настоятельно рекомендую не связывать знание данных, необходимых для представления, с контроллером. Более того для операций чтения можно не использовать контроллер, контроллер предназначен для обработки пользовательского ввода, что в классическом MVC, что в Модели 2.
Только сейчас дошло. Вы говорили о ViewModel, но Model и ViewModel — это разные вещи. VM используется вместо контроллера в паттерне MVVM и предназначена, в первую очередь, для SPA, десктопов и мобильных приложений. Более того VM — это Presentation Logic Layer.
Модель это обмен данными с БД и т.п.
Контроллер логика обработки этих данных и подготовка к View
Это не верно.
Обменом данными с БД занимается объект базы данных, или чаще DAO. Модель может взаимодействовать с этим объектом путем построения запросов и предоставлять интерфейс типа find/save как верхний уровень абстракции.
Контроллер должен только обработать пользовательский запрос и вызывать методы модели, если того требует запрос. Никаких подготовок для View. Контроллер не должен знать что нужно V для отображения. Он должен отдать то, что может. Построение пользовательского интерфейса — это уже задача View, и больше никто не должен заботиться о данных необходимых для V кроме как сам V. Тут нам помогают виджеты, помощники видов и прочие магические бесы.
Насколько я понял, вы и предлагаете использовать модель как ActiveRecord?
Нет. Это лишь один из возможных вариантов.
Как вы сделаете выборку всех активных пользователей?
Лучше всего использовать предопределенные скоупы объектов запроса. Только к моделированию это почти не относится. Скорее к зонам видимости. Если разговор о них, то да. Модель или скоупы должны знать как именно взять активных пользователей, а контроллер/виджет/сервис знают только то, что они хотят получить активных пользователей, не имея представления как это происходит и откуда идет чтение: база/файл.
activeUsers = UserModel.find().active().all()
А валидацию модели пользователя и добавление его в базу?
Data Access, в идеальном мире, осуществляется через ORM, который выстреливает заполненными моделями, а не сама модель занимается выборкой данных по привязанной таблице/файлу (исключение — паттерн ActiveRecord).
Большинство (если не все) фреймворков опускают модели до уровня доступа к данным. Модели очень сильно недооценены в примерах и гайдах. И уж на один источник, типа Microsoft, я бы не ровнялся. Я изучил множество источников, лучших практик и сам классический паттерн от «банды четырех». Уж создатели паттерна понимают лучше для чего он предназначался, чем Microsoft.
Да и в моем понимании нельзя мешать бизнес-логику, валидацию и управление данными в одной модели (у вас же это один класс?)
Для валидации используются объекты-валидаторы. Бизнес-логика конкретной предметной области, за которую отвечает модель, лежит именно в модели, верно.
Его не обязательно передавать в представление. Он может быть получен в самом представлении через внешние сервисы.
Если ваш репозиторий реализует паттерн итератор или позволяет получить все хранимые объекты, сам хранит в себе массив моделей, и имеет состояние (данные о своих моделях), то его, вполне, можно использовать как модель в представлении. Он не многим отличается от DataProvider объектов в таком случае.
Сама по себе модель существует не для того чтобы его показали в представлении. Модель это несколько больше чем просто объект с данными и бизнес-логикой для этих данных. Модель показывают в представлении, потому что это удобный способ отображения данных и взаимодействия с данными, но это не основная роль модели.
В одном из моих приложений существует модель, которая хранит состояния между запросами по средством кук. Куки считываются при каждом запросе. По внутренним правилам модель заполняется данными, которые зависят от кук. Несколько сервисов из doman logic layer зависят от того какие данные хранятся в модели. Но я нигде не отображаю данную модель. Модель может проверять куки, потому что именно модели ответственны за валидацию. И все на своих местах.
EDIT: Строго говоря, репозиторий может являться моделью, если хранит состояние между запросами и бизнес-логику для охраняемых данных.
Представление знает абсолютно все о модели, кроме того, как именно она сохраняет свои состояния
Модель — это не только класс/структура с функциональностью объекта Model/ActiveRecord или какой еще там. Я привык использовать термины «моделирование данных» и «моделирование приложения». От сюда и ее обязанности.
Модель заказов обязана хранить логику и ограничения заказов в интернет-магазине.
Если сервис/репозиторий имеет состояние, то его можно представить в роли модели.
Вы правы, эту игру действительно можно сделать проще используя angular.
Во-первых, автор оригинала построил очень странную ООП систему.
Я все никак не пойму, почему вдруг GameManager ответствует за move(), когда эта обязанность ложится на саму плитку.
Сама игра, то есть Game не должна быть синглтоном, в отличае, например, от ее настроек, так как кнопка New Game сама по себе подсказывает о создании нового инстанса игры, чистого, по существующему конфигу.
Информация о Score и high score должна лежать в отдельном объекте score, который может быть синглтоном из-за своей специфики.
Хранение в объекте грида массива с плитками вообще кажется мне диким, для этого используют репозитории, и да Вы правы, можно было бы не разделять ячейки и плитки в два разных массива, а используя один репозиторий иметь коллекцию данных в двумерном массиве.
Ну и в конце концов при перемещении плитки ее можно было бы мержить с пустой ячейкой, это легче спроектировать и поддерживать, чем разработать логику проверок и логику слияния при не пустом значении.
И так далее.
Что же касается GenerateUniqueId — это нормальная практика в системах где для некого объекта необходимо иметь один и только один глобальный идентификатор, обозначающий не только его номер в БД / Порядковый номер / Номер элемента в порядке появления, но и саму принадлежность, для избежания пересечений с другими идентификаторами других объектов системы. Подробнее тут — ru.wikipedia.org/wiki/GUID. Собственно, из за этой заметки, и заметке о создании фабрик/провайдеров и их отличие от обычных service, статья и попала ко мне в избранное. Остальное является, как мне кажется, пробой пера автора оригинальной статьи.
Так что ангуляр тут совершенно не причем, а вот у автора есть определенный ряд проблем с ООП и MVC.
Думаю, мы ни к чему не придем в этом споре. Я объясняю что правила (business rules / access rules) это часть ролей. То есть роль это совокупность правил (прав), как право редактирования собственного поста. И их накопление и интеграция просты.
С другой стороны Вы повторяете что я «зашиваю» в код какие то проверки, которые не являются на самом деле частью Access Controll системы приложения. Интересно, как же тогда через RBAC производится проверка авторства или принадлежности к региону?
Опять же, я понял плюсы атрибутов, но я не вижу никакой разницы между действиями в ABAC и правилами (правами) в RBAC. Вопрос только в том что в ABAC можно динамически изменять количество проверяемых атрибутов, но для этого нужно иметь достаточно развитый UI, который можно сделать и для RBAC(генерация классов правил опять же вариант, или некое динамическое правило, которое обращается к БД или файлу за конфигурацией).
Если говорить о финансовой стороне, лично я считаю, что добавление нового атрибута ABAC, в реальном мире, так же отдается программисту, как и написание класса нового правила (права). Мне, как программисту, сложно представить сколько будет стоить система динамически программируемая с неизвестным количеством атрибутов и связей, а так же возможностью добавления новых, непредсказуемых связей, калькулируемых атрибутов и действий, а ведь именно такая система и должна быть, чтобы ее смогли обслуживать администраторы без привлечения программистов. Если же количество действий является константой, то количество проверок и атрибутов можно через те же правила в RBAC запрограммировать на уровне конфига и предоставить к нему UI, на мой взгляд это дешевле и легче в понимании.
За сим откланяюсь и буду следить за концепцией ABAC, вдруг я изменю свое мнение.
Тут проблема терминологии. Я понимаю под моделью все что сохраняет состояние и может быть использовано для абстрактного моделирования приложения, а не то что наследуется от класса/структуры Model/CModel/TypeModel/ActiveRecord::Base и какие там еще бывают Model и AR.
Если Вы используете отдельный слой для бизнес-логики, а не пишете ее в контроллерах, то Вы по всем советам из статьи поступаете правильно. Сервис тоже может быть моделью. Вопрос терминологии, не более.
github.com/jinzhu/gorm тут лежит прекрасный ORM для Golang, который похож на Ваш подход, но это только в контексте ORM, а не фреймворка.
Лично мне всегда был ближе подход user.login() чем userService.login(&user);
За то, что пропагандирует использовать модели только для DataAccess и отображения в представлении? Оооок.
Вы когда-нибудь пробовали писать тесты для контроллера? Или может Вы можете легко инстанцировать контроллер вне приложения, без запуска всего MVC стека, перехватчиков запросов и помощников действий? Я пробовал. Это ад. Контроллеры зависимы от своих приложений и фреймворков на которых они написаны — модели нет. Вы пытались писать сервисы, где надо будет уверенным в корректности передаваемых данных? Неужели свою проверку данных сделать легче чем использовать магию моделей? Сколько языков и фреймворков Вы попробовали? C# и ASP .NET? Кто-то ковырял Revel(golang), Play/Spring(Java), Yii/Kohana/Laravel/Zend(PHP), Rails(Ruby)? Я уже не говорю про миллионы фреймворков для JS. Из одного туториала и примеров использования одного фреймворка делаем выводы по всему паттерну и игнорируем кучи трудов в интернете и на бумаге? Ооок, минусуйте дальше.
Либо Вы мешаете два паттерна, либо используете MVVM.
В любом случае, как я уже сказал, VM и M нельзя сравнивать, это разные вещи.
Я такого не говорил. Я передаю из контроллера то что контроллер может передать и настоятельно рекомендую не связывать знание данных, необходимых для представления, с контроллером. Более того для операций чтения можно не использовать контроллер, контроллер предназначен для обработки пользовательского ввода, что в классическом MVC, что в Модели 2.
Это не верно.
Обменом данными с БД занимается объект базы данных, или чаще DAO. Модель может взаимодействовать с этим объектом путем построения запросов и предоставлять интерфейс типа find/save как верхний уровень абстракции.
Контроллер должен только обработать пользовательский запрос и вызывать методы модели, если того требует запрос. Никаких подготовок для View. Контроллер не должен знать что нужно V для отображения. Он должен отдать то, что может. Построение пользовательского интерфейса — это уже задача View, и больше никто не должен заботиться о данных необходимых для V кроме как сам V. Тут нам помогают виджеты, помощники видов и прочие магические бесы.
Нет. Это лишь один из возможных вариантов.
Лучше всего использовать предопределенные скоупы объектов запроса. Только к моделированию это почти не относится. Скорее к зонам видимости. Если разговор о них, то да. Модель или скоупы должны знать как именно взять активных пользователей, а контроллер/виджет/сервис знают только то, что они хотят получить активных пользователей, не имея представления как это происходит и откуда идет чтение: база/файл.
Метод validate вызывает все зарегистрированные валидаторы.
Метод save сохраняет состояние в базу/файл/посылает на удаленный сервер.
Data Access, в идеальном мире, осуществляется через ORM, который выстреливает заполненными моделями, а не сама модель занимается выборкой данных по привязанной таблице/файлу (исключение — паттерн ActiveRecord).
Большинство (если не все) фреймворков опускают модели до уровня доступа к данным. Модели очень сильно недооценены в примерах и гайдах. И уж на один источник, типа Microsoft, я бы не ровнялся. Я изучил множество источников, лучших практик и сам классический паттерн от «банды четырех». Уж создатели паттерна понимают лучше для чего он предназначался, чем Microsoft.
Для валидации используются объекты-валидаторы. Бизнес-логика конкретной предметной области, за которую отвечает модель, лежит именно в модели, верно.
Если ваш репозиторий реализует паттерн итератор или позволяет получить все хранимые объекты, сам хранит в себе массив моделей, и имеет состояние (данные о своих моделях), то его, вполне, можно использовать как модель в представлении. Он не многим отличается от DataProvider объектов в таком случае.
Сама по себе модель существует не для того чтобы его показали в представлении. Модель это несколько больше чем просто объект с данными и бизнес-логикой для этих данных. Модель показывают в представлении, потому что это удобный способ отображения данных и взаимодействия с данными, но это не основная роль модели.
В одном из моих приложений существует модель, которая хранит состояния между запросами по средством кук. Куки считываются при каждом запросе. По внутренним правилам модель заполняется данными, которые зависят от кук. Несколько сервисов из doman logic layer зависят от того какие данные хранятся в модели. Но я нигде не отображаю данную модель. Модель может проверять куки, потому что именно модели ответственны за валидацию. И все на своих местах.
EDIT: Строго говоря, репозиторий может являться моделью, если хранит состояние между запросами и бизнес-логику для охраняемых данных.
Модель — это не только класс/структура с функциональностью объекта Model/ActiveRecord или какой еще там. Я привык использовать термины «моделирование данных» и «моделирование приложения». От сюда и ее обязанности.
Модель заказов обязана хранить логику и ограничения заказов в интернет-магазине.
Если сервис/репозиторий имеет состояние, то его можно представить в роли модели.
Во-первых, автор оригинала построил очень странную ООП систему.
Я все никак не пойму, почему вдруг GameManager ответствует за move(), когда эта обязанность ложится на саму плитку.
Сама игра, то есть Game не должна быть синглтоном, в отличае, например, от ее настроек, так как кнопка New Game сама по себе подсказывает о создании нового инстанса игры, чистого, по существующему конфигу.
Информация о Score и high score должна лежать в отдельном объекте score, который может быть синглтоном из-за своей специфики.
Хранение в объекте грида массива с плитками вообще кажется мне диким, для этого используют репозитории, и да Вы правы, можно было бы не разделять ячейки и плитки в два разных массива, а используя один репозиторий иметь коллекцию данных в двумерном массиве.
Ну и в конце концов при перемещении плитки ее можно было бы мержить с пустой ячейкой, это легче спроектировать и поддерживать, чем разработать логику проверок и логику слияния при не пустом значении.
И так далее.
Что же касается GenerateUniqueId — это нормальная практика в системах где для некого объекта необходимо иметь один и только один глобальный идентификатор, обозначающий не только его номер в БД / Порядковый номер / Номер элемента в порядке появления, но и саму принадлежность, для избежания пересечений с другими идентификаторами других объектов системы. Подробнее тут — ru.wikipedia.org/wiki/GUID. Собственно, из за этой заметки, и заметке о создании фабрик/провайдеров и их отличие от обычных service, статья и попала ко мне в избранное. Остальное является, как мне кажется, пробой пера автора оригинальной статьи.
Так что ангуляр тут совершенно не причем, а вот у автора есть определенный ряд проблем с ООП и MVC.
С другой стороны Вы повторяете что я «зашиваю» в код какие то проверки, которые не являются на самом деле частью Access Controll системы приложения. Интересно, как же тогда через RBAC производится проверка авторства или принадлежности к региону?
Опять же, я понял плюсы атрибутов, но я не вижу никакой разницы между действиями в ABAC и правилами (правами) в RBAC. Вопрос только в том что в ABAC можно динамически изменять количество проверяемых атрибутов, но для этого нужно иметь достаточно развитый UI, который можно сделать и для RBAC(генерация классов правил опять же вариант, или некое динамическое правило, которое обращается к БД или файлу за конфигурацией).
Если говорить о финансовой стороне, лично я считаю, что добавление нового атрибута ABAC, в реальном мире, так же отдается программисту, как и написание класса нового правила (права). Мне, как программисту, сложно представить сколько будет стоить система динамически программируемая с неизвестным количеством атрибутов и связей, а так же возможностью добавления новых, непредсказуемых связей, калькулируемых атрибутов и действий, а ведь именно такая система и должна быть, чтобы ее смогли обслуживать администраторы без привлечения программистов. Если же количество действий является константой, то количество проверок и атрибутов можно через те же правила в RBAC запрограммировать на уровне конфига и предоставить к нему UI, на мой взгляд это дешевле и легче в понимании.
За сим откланяюсь и буду следить за концепцией ABAC, вдруг я изменю свое мнение.