Солидарен с комментарием выше. Технология безусловно хорошая, но, к сожалению, не популярна. В основном это связано с малым числом поддерживаемых платформ.
В частности, очень популярно создавать Windows приложения на WPF, которая поддерживается на всех ОС от Microsoft, начиная от XP, если не ошибаюсь. А UWP поддерживает только десятку, и то, не все редакции(некоторые вещи только в Creators Update появляются, например).
Для развития UWP надо расширить круг поддерживаемых платформ, бэкпортировать ее на Windows 7, 8, обеспечить работу на Mac OS / Linux. Там ведь и так .NET Core под капотом, если не память не изменяет.
Увы, именно поэтому разработчики выбирают Electron, а не UWP.
Присоединяюсь к вопросу о том, как можно сломать API.
Скажите пожалуйста, уважаемые ДИТ, сейчас по телевизору и на сайтах везде идет мантра, мол, надо развивать информационные технологии, малый бизнес, поддерживать вундеркиндов как Леван, тогда почему вместо поддержки этого, безусловно, талантливого школьника(уже студента), вы вставляете палки в колеса?
Почему вы сами не идете на цивилизованный диалог? Мне казалось, что само ДИТ должно быть в нем заинтересовано, в диалоге и поддержке таких людей.
Да, Леван не акула бизнеса с 40-летним стажем и не гендиректор гугла, но он талантлив и благодаря вашему сотрудничеству могли бы выиграть все. И школьники, которые получили бы хорошее приложение, и Леван, что его приложение работает и им пользуются, и даже вы, ДИТ, показав как хорошо вы взаимодействуете с молодыми разработчиками и поддерживая открытые данные.
«Не мне — значит никому». Им ведь плевать на детей. Их интересуют только деньги. И вас они за никого считают. Типично для таких, как ДИТ и иже с ними. Впрочем, только ли для них?
связанные данные я подгружу той же вью-моделью, несвязанные — через ajax.
Внедряя сервисы в представление, мы лишаем себя возможности переиспользовать контроллер для других представлений.
Представление и работает с моделью — через контроллер, иначе зачем контроллер?
А если нужен контроллер, то зачем городить костыли через внедрение в представление, когда можно воспользоваться PartialView, AJAX-запросами и так далее? Это обеспечит также поддержку и мобильных устройств с разными SPA.
Вопрос не в том, будет ли это работать или нет, вопрос вообще лежит в другой плоскости. Согласно паттерну MVC, возможно менять само представление, при этом контроллер и модель не затрагиваются. Например, поменять список на график. В случае же, когда представление само запрашивает данные в обход контроллера, это не гарантируется. Невозможно будет заменить представление не зная особенностей логики получения этих данных. Нельзя будет отдать верстальщику и сказать, мол, сюда и сюда вставляй такое, а сюда и сюда — такое. Усложняется само представление, когда у нас нет данных изначально, а их еще надо получить.
Также теряется роль контроллера, если представление сможет само дергать данные из модели(сервис это слой модели).
А с другой стороны, также невозможно будет реализовать такое представление, когда в виде View у нас SPA или мобильное приложение.
А в случае генерации вью-моделей на стороне сервиса и передачей их через контроллер мы поддерживаем будущий переход на SPA или мобильные приложение, поддерживаем простоту представления, поддерживает правильное разделение зон ответственности и обязанностей.
Вы сами сказали, что
оно пользуется своим инжектированным интерфейсом
Почему представление должно вообще использовать сервисы, если оно может использовать контроллер, который по сути тоже реализует контракт? Тем самым мы вновь возвращаемся к генерации вью-моделей или использованию ajax/rest/graphql
Если View сам получает данные, это нарушает Separation of Concerns.
Контроллер пусть говорит не «Покажи пользователя с таким то идентификатором», а «покажи пользователя, вот он, и вот его дополнительный багаж!».
Согласен, есть проблема больших разномастных POCO, но с другой стороны, можно использовать анонимные объекты, кортежи, чтобы не писать определение нового POCO, а можно использовать ajax и подгружать данные по ходу. Можно использовать GraphQL и за один запрос получать нужные данные, а сервис там сам разберется, что отдать клиенту, как и представление — как отобразить.
Странно, просто обычно люди заявляют о другом. У меня похожие мысли. Представление не должно обладать логикой, разве что в крайне необходимых случаях. Страница не должна собирать сама себя.
Можно использовать сервисы, которые будут создавать нужные ViewModel, оставляя за контроллером лишь обязанность по делегированию запросов сервисам и обратно. Либо можно разделить ViewModel на несколько сущностей и подгружать их асинхронно.
Получение же данных самим видом переносит логику получения данных с контроллера на вид. Таким образом модель кроме выполнения своей обязанности(обновления состояния), еще и начинает получать данные, что противоречит как раз таки SRP и самому паттерну MVC.
Нет, я не спорю, внедрение в вид возможно для всяких сервисов-утилит, необходимых для непосредственного отображения. Но не в других случаях и тем более не для получения данных.
Их будет ровно столько, сколько необходимо вариантов заполнения. А в вашем случае можно сделать метод, который принимает булевые значения и на их основе заполняет те или иные поля. А можно сделать аналог Builder и потом просто использовать:
var viewModel = _service.Use(modelToProceed).WithFoo().WithBar().Proceed();
Создам один класс-фасад, который будет внедрять все 4 сервиса данных, а также несколько методов(или даже один с параметрами) для получения именно нужных данных.
Фасад здесь применим, поскольку он может логически отделить работу со справочниками от остального кода. Также он может предоставлять доступ к внедренным сервисам.
Я думаю их использование в 3 контроллерах уже очевидный повод вынести код, а не бездумно копипастить. Как вариант я предложил фасад.
А называю я его бизнес-логикой, потому что скорее всего вы получаете эти данные из БД, а в ходе развития приложения способы получения данных усложняются. Возможно, вам потом придется каким-либо образом фильтровать эти самые данные, или сортировать, или еще допустим рассчитывать на их основе другие какие-то значения, и так далее.
.
Можно делать цепочки запросов, можно делать гонки запросов и т.п., и все декларативно и реактивно.
В частности, очень популярно создавать Windows приложения на WPF, которая поддерживается на всех ОС от Microsoft, начиная от XP, если не ошибаюсь. А UWP поддерживает только десятку, и то, не все редакции(некоторые вещи только в Creators Update появляются, например).
Для развития UWP надо расширить круг поддерживаемых платформ, бэкпортировать ее на Windows 7, 8, обеспечить работу на Mac OS / Linux. Там ведь и так .NET Core под капотом, если не память не изменяет.
Увы, именно поэтому разработчики выбирают Electron, а не UWP.
Скажите пожалуйста, уважаемые ДИТ, сейчас по телевизору и на сайтах везде идет мантра, мол, надо развивать информационные технологии, малый бизнес, поддерживать вундеркиндов как Леван, тогда почему вместо поддержки этого, безусловно, талантливого школьника(уже студента), вы вставляете палки в колеса?
Почему вы сами не идете на цивилизованный диалог? Мне казалось, что само ДИТ должно быть в нем заинтересовано, в диалоге и поддержке таких людей.
Да, Леван не акула бизнеса с 40-летним стажем и не гендиректор гугла, но он талантлив и благодаря вашему сотрудничеству могли бы выиграть все. И школьники, которые получили бы хорошее приложение, и Леван, что его приложение работает и им пользуются, и даже вы, ДИТ, показав как хорошо вы взаимодействуете с молодыми разработчиками и поддерживая открытые данные.
А автор молодец. Успехов ему.
Внедряя сервисы в представление, мы лишаем себя возможности переиспользовать контроллер для других представлений.
И только после этого у нас идет отображение.
Я же предлагаю вариант с меньшим числом потоков данных.
— Бизнес логика, тут хотят создать нового пользователя! Оп, спасибо за него! Вьюха, лови!
Все. И ничего больше.
А если нужен контроллер, то зачем городить костыли через внедрение в представление, когда можно воспользоваться PartialView, AJAX-запросами и так далее? Это обеспечит также поддержку и мобильных устройств с разными SPA.
Также теряется роль контроллера, если представление сможет само дергать данные из модели(сервис это слой модели).
А с другой стороны, также невозможно будет реализовать такое представление, когда в виде View у нас SPA или мобильное приложение.
А в случае генерации вью-моделей на стороне сервиса и передачей их через контроллер мы поддерживаем будущий переход на SPA или мобильные приложение, поддерживаем простоту представления, поддерживает правильное разделение зон ответственности и обязанностей.
Вы сами сказали, что
Почему представление должно вообще использовать сервисы, если оно может использовать контроллер, который по сути тоже реализует контракт? Тем самым мы вновь возвращаемся к генерации вью-моделей или использованию ajax/rest/graphql
Контроллер пусть говорит не «Покажи пользователя с таким то идентификатором», а «покажи пользователя, вот он, и вот его дополнительный багаж!».
Согласен, есть проблема больших разномастных POCO, но с другой стороны, можно использовать анонимные объекты, кортежи, чтобы не писать определение нового POCO, а можно использовать ajax и подгружать данные по ходу. Можно использовать GraphQL и за один запрос получать нужные данные, а сервис там сам разберется, что отдать клиенту, как и представление — как отобразить.
Можно использовать сервисы, которые будут создавать нужные ViewModel, оставляя за контроллером лишь обязанность по делегированию запросов сервисам и обратно. Либо можно разделить ViewModel на несколько сущностей и подгружать их асинхронно.
Получение же данных самим видом переносит логику получения данных с контроллера на вид. Таким образом модель кроме выполнения своей обязанности(обновления состояния), еще и начинает получать данные, что противоречит как раз таки SRP и самому паттерну MVC.
Нет, я не спорю, внедрение в вид возможно для всяких сервисов-утилит, необходимых для непосредственного отображения. Но не в других случаях и тем более не для получения данных.
Выносить логику на сторону представления — попахивающий код. А сервисы можно поддерживать.
Это просто пример, вариантов масса.
Фасад здесь применим, поскольку он может логически отделить работу со справочниками от остального кода. Также он может предоставлять доступ к внедренным сервисам.
А называю я его бизнес-логикой, потому что скорее всего вы получаете эти данные из БД, а в ходе развития приложения способы получения данных усложняются. Возможно, вам потом придется каким-либо образом фильтровать эти самые данные, или сортировать, или еще допустим рассчитывать на их основе другие какие-то значения, и так далее.