Вы WinPhone app совсем забросили, или как? Кстати, с какой-то версии стало дико неудобно в несколько кликов добавлять новое слово. Раньше можно было в один клик, а ещё оно тормозит сильно на Lumia 920, а это не самый слабый WinPhone.
Марк Симан написал мне в блоге в комментариях, что он считает, что когда у ViewModel столько зависимостей, то нарушен SRP. Возможно, он прав. Но, что делать если в реальности три зависимости используются для создания модели, а остальные — просто утилитарные. Кто-нибудь как-то решал эту проблему более элегантным способом, чем описано в этой статье?
Control Flow осуществляет ViewModel, поэтому и модальные диалоги ей вызывать. Это если паттерн MVVM, а вот если MVPVM, то, м.б. можно и как-то по-другому, но не уверен, у меня нет соответствующего опыта.
Рассмотрим WPF-app с MVVM в качестве UI-паттерна.
Два вопроса:
1. Как вы считаете, если ViewModel требует в конструкторе две-три зависимости и сама их не использует, а только конструирует Model с помощью них, имеется ли здесь проблема транзитивных зависимостей?
2. Если на первый вопрос ответ положительный, то что такое Command Bus и как это поможет в таком случае?
Я тоже так думаю. Это называется принципом Голливуда: «не звоните нам, мы сами вам позвоним». Хотя я не очень люблю эту метафору применительно к DI с помощью IoC.
Если объекту А для предоставления своих услуг нужен другой объект B, и только объект A знает как воспользоваться B так, чтобы предоставить свои услуги корректно, то что в этом не так?
Поэтому теперь надо повсюду, даже если вы не пишите монструозный EF, использовать рефлекшн для изменения приватных полей и прикрываться тем, что существуют популярные фрэймворки, которые так делают?
Не знаю как в PHP, могу сказать за WPF и ASP.NET. В такого рода приложениях мы находим централизованное место и через него и только через него происходит resolve и больше нигде!
Service Locator нарушает инкапсуляцию класса, если он используется непосредственно в классе. Но даже в данном примере, что нам мешает использовать Service Locator для определения параметров вызова конструктора?
Мы решили проблему, перенеся ответственность для клиента и сделали зависимости очевидными. Если клиент будет использовать Service Locator — право клиента, значит сам себе злобный буратино.
На том же PHP я избегаю зависимости моих классов от Service Locator (даже явной, через параметры), предпочитая получать в конструкторе или сеттерах конкретные инстансы классов/интерфейсов.
Извините, не совсем понял. Чем отличается ваш подход от инжектирования зависимостей через конструктор?
по-моему лучше чем захардкоженная зависимость от конкретных классов или, пускай, интерфейсов как в примере.
Если это reusable business-object, то чем будет лучше сокрытие зависимостей от клиента?
Грань есть. Есть нормативная документация, написанная в соответствии с научными исследованиями. Я близко работаю с инженерами, программирующими устройства и точно знаю, что они всегда в курсе всего, что они делают и на очень глубоком уровне.
По поводу WinPhone, ну, не знаю, подавляющая часть приложений летает, вроде бы.
Два вопроса:
1. Как вы считаете, если ViewModel требует в конструкторе две-три зависимости и сама их не использует, а только конструирует Model с помощью них, имеется ли здесь проблема транзитивных зависимостей?
2. Если на первый вопрос ответ положительный, то что такое Command Bus и как это поможет в таком случае?
В вашем коде объекты не зависят от других объектов?
Мы решили проблему, перенеся ответственность для клиента и сделали зависимости очевидными. Если клиент будет использовать Service Locator — право клиента, значит сам себе злобный буратино.
Извините, не совсем понял. Чем отличается ваш подход от инжектирования зависимостей через конструктор?
Если это reusable business-object, то чем будет лучше сокрытие зависимостей от клиента?