Ага. Даже у изобретателя, майкрософта, ничего про такой официальный подход нету - они везде и сразу говорили, что это не догма и не жесткий паттерн. А если смотреть в разные источники (а не в один "официальный"), так и вовсе выяснится, что каждый делает по-своему
Он может быть сколь угодно проще и гибче, только это не MVVM
Не надо быть догматиком. Все современные паттерны и модели как раз и придуманы для гибкости, понятности и maintainability, а не для чего-то еще
Не говоря уж о том, что модель, в которой перемешана BL&DAL прямо нарушает сингл респонсибилити.
Почему же бессмысленно, есть ведь и другие паттерны, при помощи которых можно оценить подход
Ваш, насколько я понял, предполагает в Model наличие data access layer & business logic layer; view+viewModel это presentation
И чем этот подход отличен от древнего майкрософтовского Document-View? Не говоря уж о том, что Model получает чересчур много responsibilities, a viewModel, наоборот, служит довольно-таки бесполезным man in the middle
Подход же вида Model - DAL, viewModel - BL, view - presentation и проще, и более гибкий
Да, вот только domain model – это не просто данные, это данные и поведение
там прям в цитате написано - or to the data access layer, which represents content (a data-centric approach)
Никто не говорит, что БЛ там вообще быть не должно. Может быть, может не быть, it's not carved in stone
Интерфейс к интерфейсу? Это как?
очень просто
У меня есть API, для пользователей этого API я выставлю наружу view, сиречь класс, который ничего не делает, просто принимает данные и команды и передает их во viewModel
В зависимости от конфигурации за этим view могут быть разные viewmodels
View - это абстракция, каким смыслом вы ее наполните, тем она и будет
In this respect, the viewmodel is more model than view, and handles most if not all of the view's display logic
Нет, это не бизнес-логика. Это просто "трансформация данных/команд, которые приходят от view или от model".
Хы, а трансформация данных по определенным правилам - это не БЛ что ли?
Я говорю, что все эти mvc/mvp/mvvm - это абстракции, не ставящие жестких рамок. Хотите запихнуть всю БЛ в модел - ради бога. Хотите вo вьюмодел - с нашим удовольствием Нету жестких правил, нету
Model refers either to a domain model, which represents real state content (an object-oriented approach), or to the data access layer, which represents content (a data-centric approach) https://en.wikipedia.org/wiki/Model–view–viewmodel
А что еще?
Интерфейс к API, например
Я выше написал, что ViewModel "занимается UI-логикой
не, UI логикой занимается view, у viewModel и ссылки-то на view нет. Вы, наверное, с MVP путаете
A viewModel занимается трансформацией данных/команд, которые приходят от view или от model. Эта трансформация и есть БЛ, по крайней мере, часть ее
Н-да? In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program. https://en.wikipedia.org/wiki/Business_logic
Как можно легко увидеть, то, что происходит во viewModel точно так же является бизнес логикой Более того, нет никаких препятствий или правил против размещения БЛ во viewModels - достаточно представить, что она может быть разной для одного и того же набора данных, т.е., для одной и той же model Многие источники так и прямо говорят, model - это просто данные. Они могут отбираться по разным БЛ правилам, но это вовсе не значит, что БЛ лежит исключительно в модели. Так что вопрос в основном в том, как мы будем разделять БЛ, какая ее часть касается данных, и какая - их преобразований, т.к. view - это необязательно UI Редуцируя viewModel до примитивного передатчика между Model и View, вы просто перегружаете Model ненужными ей правилами БЛ
Ну так да, viewModel как раз этим самым и отделяет бизнес логику от view - тем, что она ее и содержит. Иначе какой в ней смысл, можно просто view/model обойтись
Наверное от компании зависит. Мне все рекрутеры постоянно говорят, мол, оо, с лояльность проблем нет, мы видим, это хорошо. Хотя может польстить хотят, фиг их знает
за грантами он будет бегать, а не нерешенные проблемы решать:)) Ну если не профессор в канаде или в европе, там профессором стал - и уже можно начинать ковырять в носу
что до готовых технологий девам которые они одинаково везде используют - это от профиля работы зависит. Понятно, что если работа сводится к перекладыванию jsonов из таблички в табличку(ц), то лучше там не задерживаться, но не все ж работы такие
Я, когда в Канаду попал, и начал работать, на одном корпоративе одной конторы прям в осадок выпал, когда руководство начало поздравлять работников - кто-то 13 лет уже работает, а кто-то и больше 20ти
Можно, конечно, рассматривать их как тормозных старперов - а можно как редких профессионалов в своей области. Никто почему-то не упрекает, скажем, профессоров физики в том, что они не меняют направление на биологию/астрономию/химию каждые 5 лет
Почему в девелопменте софта должно быть по-другому? Или работы настолько рутинны и однообразны, что сидеть там 5 лет просто потеря времени?
Ну и давайте не будем забывать, что в крупных компаниях есть еще и движение по горизонтали, зачастую с радикальной сменой поля деятельности
так у вас софтина не работает как надо, клиенты перетекают к конкурентам
это если они есть, и у них не хуже
Обычно, у них такие же проблемы. Большинство софта, который на рынке давно и даже стандарт - редкостное г в плане кода, там просто чюдовищный легаси
С точки зрения отдельного разработчика конечно же интереснее из раза в раз писать поделия-однодневки
поделия очень разные бывают. Можно пилить сайты, когда вся работа сведется к перекладыванию json-ов из таблички в табличку, а может и нет. Я вот, помню, работал на одну офшорку - ни одной одинаковой задачи не было за 2 года. Может, повезло, конечно
может быть и много, но никогда не бесконечно
ну так и нормально написанное приложение не увеличивает память постоянно
разница в том, перепишут вашу софтину с нуля через два года или через десять.
кто ж ее через два года переписывать будет-то:)) Бабло надо рубить, а не переписывать
Если у нас stop the world GC: чем больше потоков плодят мертвые объекты, тем дольше цикл сборки мусора, который останавливает все потоки, т.е. суммарное время простоя ядер квадратно пропорционально числу активных потоков.
это, снова-здорово, если у нас вдруг перестало хватать памяти и запустился gc. А памяти у нас много, как уже было сказано
а с чего вы взяли что доп разраб обязательно потребуется?
а они всегда требуются, если мы хотим чего-то большего
Если делаешь коробку, например, на доп улучшения надо кого-то нанимать, т.к. остальные уже заняты - новые фичи, апгрейды и прочее, запланированное менеджментом, и отложить их нельзя
ну то есть вы предполагаете что надо было потратить больше времени на оптимизацию, да? Или просто закидать железом с горкой?
если программа хреново написана, то да. Просто потому, что увеличение числа ядер ничего не даст
Но это от языка не зависит вообще; я-то говорил о ситуациях, когда ваше аккуратное использование памяти легко бьется покупкой доп планок (если совсем примитивно), или доп. виртуальных машин
в среднем и чаще всего Речь не идет о высокопроизводительном софте, которого проценты от общего. 90% софта вполне попадают под "общее"
опять же, это "иногда" а не "всегда".
да почти всегда
доп дев обойдется конторе в 70-100 тыс в год (это в нашем небогатом квебеке, например), нарастить облако будет сильно дешевле
ну вот буквально сегодня я словил факап на проде потому что, как оказалось, кеширующая прокся на go не способна держать жалкие 2k rps на 4-х ядрах.
так тут либо а) прокся просто криво написана б) либо да, затык по производительности. Я б поставил на первое, особенно если выяснится, что данные хреново параллелятся на эти самые 4 ядра
надо автоматизировать
есть же veracode, например
Ага. Даже у изобретателя, майкрософта, ничего про такой официальный подход нету - они везде и сразу говорили, что это не догма и не жесткий паттерн. А если смотреть в разные источники (а не в один "официальный"), так и вовсе выяснится, что каждый делает по-своему
Не надо быть догматиком. Все современные паттерны и модели как раз и придуманы для гибкости, понятности и maintainability, а не для чего-то еще
Не говоря уж о том, что модель, в которой перемешана BL&DAL прямо нарушает сингл респонсибилити.
Почему же бессмысленно, есть ведь и другие паттерны, при помощи которых можно оценить подход
Ваш, насколько я понял, предполагает в Model наличие data access layer & business logic layer; view+viewModel это presentation
И чем этот подход отличен от древнего майкрософтовского Document-View?
Не говоря уж о том, что Model получает чересчур много responsibilities, a viewModel, наоборот, служит довольно-таки бесполезным man in the middle
Подход же вида Model - DAL, viewModel - BL, view - presentation и проще, и более гибкий
там прям в цитате написано - or to the data access layer, which represents content (a data-centric approach)
Никто не говорит, что БЛ там вообще быть не должно. Может быть, может не быть, it's not carved in stone
очень просто
У меня есть API, для пользователей этого API я выставлю наружу view, сиречь класс, который ничего не делает, просто принимает данные и команды и передает их во viewModel
В зависимости от конфигурации за этим view могут быть разные viewmodels
View - это абстракция, каким смыслом вы ее наполните, тем она и будет
ну нате вам другую ссылку
https://www.geeksforgeeks.org/difference-between-mvp-and-mvvm-architecture-pattern-in-android/
Хы, а трансформация данных по определенным правилам - это не БЛ что ли?
Я говорю, что все эти mvc/mvp/mvvm - это абстракции, не ставящие жестких рамок. Хотите запихнуть всю БЛ в модел - ради бога. Хотите вo вьюмодел - с нашим удовольствием
Нету жестких правил, нету
да хотя бы и википедия
Model refers either to a domain model, which represents real state content (an object-oriented approach), or to the data access layer, which represents content (a data-centric approach)
https://en.wikipedia.org/wiki/Model–view–viewmodel
Интерфейс к API, например
не, UI логикой занимается view, у viewModel и ссылки-то на view нет. Вы, наверное, с MVP путаете
A viewModel занимается трансформацией данных/команд, которые приходят от view или от model. Эта трансформация и есть БЛ, по крайней мере, часть ее
Н-да?
In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
https://en.wikipedia.org/wiki/Business_logic
Как можно легко увидеть, то, что происходит во viewModel точно так же является бизнес логикой
Более того, нет никаких препятствий или правил против размещения БЛ во viewModels - достаточно представить, что она может быть разной для одного и того же набора данных, т.е., для одной и той же model
Многие источники так и прямо говорят, model - это просто данные. Они могут отбираться по разным БЛ правилам, но это вовсе не значит, что БЛ лежит исключительно в модели.
Так что вопрос в основном в том, как мы будем разделять БЛ, какая ее часть касается данных, и какая - их преобразований, т.к. view - это необязательно UI
Редуцируя viewModel до примитивного передатчика между Model и View, вы просто перегружаете Model ненужными ей правилами БЛ
и это не бизнес-логика?
И что же этот посредник конретно делает?
Ну так да, viewModel как раз этим самым и отделяет бизнес логику от view - тем, что она ее и содержит. Иначе какой в ней смысл, можно просто view/model обойтись
Эээ.. А разве ViewModel - это не бизнес-логика? А Model - только данные?
очуметь как непросто все
вот поэтому я сразу подавался на иммиграцию в канаду, это проще и быстрее!!
ну, в 2005 году, по крайней мере было проще
Наверное от компании зависит. Мне все рекрутеры постоянно говорят, мол, оо, с лояльность проблем нет, мы видим, это хорошо. Хотя может польстить хотят, фиг их знает
за грантами он будет бегать, а не нерешенные проблемы решать:)) Ну если не профессор в канаде или в европе, там профессором стал - и уже можно начинать ковырять в носу
что до готовых технологий девам которые они одинаково везде используют - это от профиля работы зависит. Понятно, что если работа сводится к перекладыванию jsonов из таблички в табличку(ц), то лучше там не задерживаться, но не все ж работы такие
про 5 лет на одном месте
Я, когда в Канаду попал, и начал работать, на одном корпоративе одной конторы прям в осадок выпал, когда руководство начало поздравлять работников - кто-то 13 лет уже работает, а кто-то и больше 20ти
Можно, конечно, рассматривать их как тормозных старперов - а можно как редких профессионалов в своей области. Никто почему-то не упрекает, скажем, профессоров физики в том, что они не меняют направление на биологию/астрономию/химию каждые 5 лет
Почему в девелопменте софта должно быть по-другому? Или работы настолько рутинны и однообразны, что сидеть там 5 лет просто потеря времени?
Ну и давайте не будем забывать, что в крупных компаниях есть еще и движение по горизонтали, зачастую с радикальной сменой поля деятельности
да не шибко положительно в штатах к частой смене относятся
Наоборот, больше ценится лояльность компании
это если они есть, и у них не хуже
Обычно, у них такие же проблемы. Большинство софта, который на рынке давно и даже стандарт - редкостное г в плане кода, там просто чюдовищный легаси
поделия очень разные бывают. Можно пилить сайты, когда вся работа сведется к перекладыванию json-ов из таблички в табличку, а может и нет. Я вот, помню, работал на одну офшорку - ни одной одинаковой задачи не было за 2 года. Может, повезло, конечно
ну так и нормально написанное приложение не увеличивает память постоянно
кто ж ее через два года переписывать будет-то:)) Бабло надо рубить, а не переписывать
это, снова-здорово, если у нас вдруг перестало хватать памяти и запустился gc. А памяти у нас много, как уже было сказано
увы, это реалии отрасли
эээ.. это, мягко говоря, слабо обоснованное умозаключение
эээ.. gc чаще всего и распределяет ее б-м идеально - в непрерывном куске
да вакансии посмотрите на работных сайтах
а они всегда требуются, если мы хотим чего-то большего
Если делаешь коробку, например, на доп улучшения надо кого-то нанимать, т.к. остальные уже заняты - новые фичи, апгрейды и прочее, запланированное менеджментом, и отложить их нельзя
если программа хреново написана, то да. Просто потому, что увеличение числа ядер ничего не даст
Но это от языка не зависит вообще; я-то говорил о ситуациях, когда ваше аккуратное использование памяти легко бьется покупкой доп планок (если совсем примитивно), или доп. виртуальных машин
в среднем и чаще всего
Речь не идет о высокопроизводительном софте, которого проценты от общего. 90% софта вполне попадают под "общее"
да почти всегда
доп дев обойдется конторе в 70-100 тыс в год (это в нашем небогатом квебеке, например), нарастить облако будет сильно дешевле
так тут либо а) прокся просто криво написана б) либо да, затык по производительности. Я б поставил на первое, особенно если выяснится, что данные хреново параллелятся на эти самые 4 ядра
При чем тут язык?