Всем привет. Вопрос к гуру DI (dependency injection). Я во всех проектах использую стандартный DI через конструктор, но на практике столкнулся с проблемой, если в проекте к примеру 100 VM и каждая наследуется от ViewModelBase и по каким то причинам во ViewModelBase понадобилось добавить новую иньекцию, то придется в каждой VM добавлять иньекцию в конструктор и затем передовать в base. Это очень не удобно. В одном из проектов видел, что во VM передаются не иньекции, а единственный параметр IContext, с единственным методом Reslove. Таким образом даже если во ViewModelBase понадобиться новая зависимость, то достаточно будет прописать одну строчку в конструкторе а не переписывать все уже существующие ViewModel. Собственно вопрос, может кто то уже использовал данный метод, или хотел но отказался по ряду каких то причин, какие подводные камни могут всплыть при использовании такого подхода?

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

это типа доп класса, который тянет нужные зависимости, который потом во vm резолвится?

Слушай Сова, откуда у тебя столько времени на активность? ты тут вообще круглые сутки

Я полифазку тренирую

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

Я согласен, что в базовой VM не должно быть много зависимостей, но когда у тебя всего одна зависимость в базовой vm и тебе нужно прокинуть вторую, то тебе все равно придется в каждой из 100 vm добавить ее и прокинуть в базовый класс. То есть всего добавление одной дополнительной зависимости затрагивает как минимум 100 классов

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

Излишнюю лень обычно не оттестировать

мейби, но менять в 100 классах шаблонные изменения, это уж увольте, мазахизм. Сидишь, копировать - вставить, и так далее. А завтра приходит руководство и выдает новую, задачу, в которой опять нужно что то в базовую VM прокидывать, и понеслось сначала. Мне кажется, должно быть более developer friendly решение.

Ну, как по мне, именно в програмирование лень - двигатель прогресса и автоматизации.

не совсем так как по мне. Пользовательская лень - да. Но далеко не программиста

Я говорю именно про лень программиста, например CI. Можно сказать, это экономит время и деньги, но все сводиться к лени как не крути

Я согласен что однотипные задачи - скучные и от того их не хочется делать.

Зависимости прокидывают не просто так. А для того чтобы ты мог не завязываться на IoC в тестовом фреймворке и писал юниттесты, тестировал маленькие кусочки твоей программы

Так а каким образом IContext завязывается на каком то IoC??

Всем привет, можите посоветовать, можно ли сделать что-то типа ивента который будет ждать пока в андроид части пройдет метод, чтобы потом выполнить код в ПСЛ?

Это значит что ты будешь настраивать моки для тестового проекта каждый раз когда у тебя добавляется новый сервис и регистрировать их в ioc.

Я согласен, что в базовой VM не должно быть много зависимостей, но когда у тебя всего одна зависимость в базовой vm и тебе нужно прокинуть вторую, то тебе все равно придется в каждой из 100 vm добавить ее и прокинуть в базовый класс. То есть всего добавление одной дополнительной зависимости затрагивает как минимум 100 классов

Есть способ проще - не использовать наследование реализаций

Тогда нарушится DRY

Это можно сделать с помощью тасков. Копай в сторону TaskCompletionSource

Это можно сделать с помощью тасков. Копай в сторону TaskCompletionSource

канонично

Нет. Наследование реализаций - не единственный, не главный и не частый способ избежать дублирования

Тогда события. Создаешь интерфейс с событием, пишешь реализацию в платформозависимом проекте, и вызываешь это событие когда тебе нужно, а в PCL подписываешьсы на него

TaskCompletiomSource как бы и нужно

получается да, TaskCompletionSource + event

На пример?

Можно уже без TaskCompetionSource если используешь события

Композиция. Вместо наследования реализации - ссылка на объект с выделенной общей функциональностью.

Это усложняет код

кстати да, что-то я перемудрил

Напротив - теперь в 100 классов из-за одной зависимости ничего вносить не надо. Также нет ограничений на единственность класса с общей функциональностью.

event

Здравствуйте. Есть добавление из Jsonа элементов в Layout, Тут реализация https://gist.github.com/jarakys/fd42c510b057e7b599ab1da4c7942a2c Проблема заключается в том, что в Child оно то добавляется, но отрисовываться не хочет, как заставить его рисоваться ?

А что за лейаут? И в json лежат классы, которые от View наследуются?

AbsoluteLAyout. Да, там лежат классы которые наследуются от View, так-то они отрисовываются, но именно когда я гружу их из JSON отрисовки нет

Композиция. Вместо наследования реализации - ссылка на объект с выделенной общей функциональностью.

а пример одного view из этого json можно?

Да, но когда я добавлял эти фигуры на Layout я тоже не указывал эти свойства и оно рисовало как надо

вы ещё не попробовали совет из моего первого ответа

absolute.Children.Add(new BoxView() {BackgroundColor = Color.Red}); - пробовал, оно заработало

absolute.Children.Add(new BoxView() {BackgroundColor = Color.Red}); - пробовал, оно заработало

т.е. те которые приходят из Вьюхи по наследованию я просто отбрасываю

в любом случае попробуйте вручную добавить свою View, как сделали с BoxView а также попробуйте добавить обязательные свойства LayoutFlags и LayoutBounds иначе зачем вообще AbsoluteLayout, если им по сути и не пользуетесь

LayoutFlags и LayoutBounds вообще ни разу не обязательные) Он и так отрисовывает все элементы, просто по умолчанию размещает их в верхнем левом углу с их размерами. Проблема явно не в них

Добавли мой View вручную, он отобразился, просмотрел его WidthRequest он равен минус один, точно так же и у View из JSON

Всем привет! Скажите, почему все ругают xamarin? Какие у него недостатки по сравнению с нативом и другими, ему подобными инструментами?

Просто я из мира вэб, в котором много решений для нативной разработки, хотя лично я выделяю только одно - angular. Но почему-то у создателей nativescript не хватило фантазии написать подобие xamarin.forms и необходимо все шаблоны покрывать ифами. Для меня не разница важна скорости в пределах от 0,01 до 0,1, а важны нервы, запас которых дико расходуется, когда пишешь на чем-то кривом. И вот я какой день выбираю на чем именно написать первое приложение и так и не могу определится, так как все советуют что-то, но не могут внятно объяснить, почему именно они это советуют. То есть они советуют только потому, что именно им это показалось лучше.

разве это не одина платформа?

и под нативом я имел ввиду родной натив.

а что делает родной натив родным?

и под нативом я имел ввиду родной натив.