1274 / 975 / 113
Регистрация: 12.01.2010
Сообщений: 1,971
|
||||||
1 | ||||||
MVVM + DI + IOC = а что делать с дочерними VM?04.02.2016, 22:29. Показов 1565. Ответов 5
Метки нет (Все метки)
допустим есть Company, у него есть список Employee, у каждого список Addresses...
есть окно, список Company, справа список Employee, а где-то-пофиг-где вложенный список Addresses делается CompanyListViewModel у которого есть список...погодите-ка, не Employee, а EmployeeViewModel потому что нужна кнопка, сортировка, фильтрация, валидация, какой-нибудь IsChecked и что угодно, короче это 100% EmployeeViewModel со своей логикой и сервисами в конструкторе иии собственно что дальше-то?
допустим сделать фабрику дочерних Viewmodel ...но какую? EmployeeViewModelFactory с одним методом...а как же IOC? как же передавать всю мишуру сервисов..тогда смысл в фабрике? Добавлено через 21 минуту как-нибудь то мы сделали, но неужели нет какого-то шаблона и best practice? умники блоггеры никогда не уходят дальше 1 уровня иерархи в своих примерах со сраными twitter-friends, такое ощущение что ребята сроду никогда ничего боевого не писали с использованием MVVM надо всю цепочку честно делать ВМ, Код
КомпанияЛистВм, ----КомпанияВм, --------СотрудникСписокВм, ------------СотрудникВм, ----------------АдресСписокВм, --------------------АдресВм да всё это в одном окне, нет не будет тормозить, нужны все и сразу в виде табов + списки с вложенными списками можно схлопнуть всё это в 1 viewmodel, но тогда вернется старый добрый MainForm на 5000 строк
0
|
04.02.2016, 22:29 | |
Ответы с готовыми решениями:
5
Что такое DI, IoC, паттерны. ? Делать динамическую игру через mvvm - плохая идея? подскажите что делать при вводимых данных 10 25 и 5 20 программа работает не правильно должна выводить 135 подскажите что делать Что делать, когда не знаешь, что делать? |
12073 / 8383 / 1280
Регистрация: 21.01.2016
Сообщений: 31,578
|
|
05.02.2016, 06:33 | 2 |
Прочитав всё вышеизложенное я не понял главного: а в чём вопрос?
как же передавать всю мишуру сервисов - это вопрос? Если да, то используйте контейнер внедрения зависимостей или статически типизированный локатор сервисов (а не "обычный", параметризированный - его не любят и правильно). Или вы не это имели в виду?
0
|
1274 / 975 / 113
Регистрация: 12.01.2010
Сообщений: 1,971
|
|
05.02.2016, 08:46 [ТС] | 3 |
но ведь тогда это антипаттерн сервис-локатор
одно дело главное окно так создать, а другое в сами вм передавать контейнер минус этого паттерна в том, что совершенно непонятно что делает класс и какие у него зависимости
0
|
12073 / 8383 / 1280
Регистрация: 21.01.2016
Сообщений: 31,578
|
|
05.02.2016, 09:12 | 4 |
Поэтому я и добавил фразу
статически типизированный сервис-локатор. Т.е. просто фабрика создающая близкие по смыслу (или модулю, где она находится) объекты. Для создания каждого объекта используется собственный фабричный метод. По интерфейсу такой фабрики (локатора) всегда будет видно, что и как она может создавать. Такой подход одобряется многими противниками сервис-локаторов (по интерфейсу которых вообще ничего не понятно).А вот с этим соглашусь. Есть такое. И тут особо ничего и не придумано. Если нужно, чтобы класс мог обращаться к какому-то другому классу, то нужно либо на него (либо на локатор/фабрику, который знает как его получить) явно ссылку передать - внедрить зависимость - либо использовать приём "контекст" - суть общедоступный класс того же локатора/контейнера/фабрики. Главное, чтобы для каждого модуля была своя такая фабрика, а не одна единственная "божественная", умеющая создавать всё и вся. Добавлено через 13 минут Рекомендую ознакомиться с такой вот замечательной книгой "Внедрение зависимостей в .NET" за авторством Марка Симана. В ней Марк рассматривает все возможные (и несколько невозможных, чисто для фана) способов организации внедрения зависимостей. И контейнеры рассматривает. В общем, всё что с этим связано. И он же сам приходит к мысли, что внедрить зависимость можно только двумя способами - явно передать зависимость (через конструктор, свойства или метод) или используя "контекст". Причём он приводит веские доводы в пользу того, что прилично так озадачившись, можно свести к минимуму использование "контекста". Но полностью от него отказаться, увы, не получится.
0
|
1838 / 1346 / 427
Регистрация: 10.06.2011
Сообщений: 2,126
|
|||||||||||||||||||||
05.02.2016, 10:16 | 5 | ||||||||||||||||||||
Вот это правильная мысль. Но можно и без контекста. Мне он не нравится, ибо он тот же ServiceLocator.
В своей книге Симан предлагает такое решение: для создания временных зависимостей использовать фабрики, которые бы инкапсулировали внутри себя внедрение зависимостей в создаваемые объекты. Например: CompanyViewModel
EmployeeViewModelFactory
EmployeeViewModel
AdressViewModelFactory
Все фабрики регистрируются в DI-контейнере, как одиночки, т.е. всегда будет внедрятся один и тот же экземпляр каждой из фабрик. В данном коде каждому объекту внедряются только необходимые ему зависимости. DI-контейнеры при этом не внедряются, ибо это против правил. Ключевое слово new вынесено в фабрики, которые сами являются зависимостями. Тут, конечно, минус, что для каждой ViewModell'и создаётся своя фабрика, но зато правила DI соблюдены.
0
|
12073 / 8383 / 1280
Регистрация: 21.01.2016
Сообщений: 31,578
|
|
05.02.2016, 10:52 | 6 |
Ну, если ViewModell'и идеологически близки друг к другу, то можно их и в одной фабрике создавать. Хотя это не всегда может быть красиво, но в небольших приложениях вполне себе приемлемо.
Просто горы фабрик плодить для каждой мелкой сущности тоже не вариант.
0
|
05.02.2016, 10:52 | |
05.02.2016, 10:52 | |
Помогаю со студенческими работами здесь
6
Разговор ни о чем или что делать, чтобы ничего не делать? Что может делать делать указанный скрипт Что такое MVVM? MVVM Что относится к View? MVVM паттерн. Что такое ViewModel? MVVM Binding что я не так делаю ? Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |