Единство с репозиториями

Я новичок в Unity IoC (DI в целом), прочитал много документов и посмотрел несколько часовых видеороликов на канале 9. Даже после всего этого я не нашел ни одного примера, демонстрирующего набор функций в находясь в поиске.

Все онлайн показало, что вы можете создать репозиторий и зарегистрировать его в контейнере единства. Затем я могу внедрить репозиторий в мои конструкторы моделей представлений. В моем конкретном приложении мне нужно поддерживать ParseCloud, Box, DropBox и OneDrive, а также несколько реализаций интерфейса. Поэтому я планировал создать четыре репозитория, по одному для каждого сервиса.

Имеет ли смысл регистрировать в Unity одну абстрактную фабрику репозиториев, которую модели представления могут использовать для получения правильного репозитория в зависимости от того, для чего настроено приложение?

Еще одна вещь, которую поддерживает приложение (приложение задач), — это несколько реализаций ITask, поэтому у меня есть BasicTask, GTDTask, GoogleTask. Поэтому я подумал, что мне понадобится метод репозитория, который мог бы обрабатывать каждую реализацию и хранить реализацию в правильном облачном сервисе. Как мне достичь этой абстракции с помощью Unity? Лучше всего просто зарегистрировать все типы ITask и иметь абстрактный репозиторий, определяющий, какой тип принадлежит какому репозиторию, на основе службы, в которую вошел пользователь?

Я хочу, чтобы модели просмотра страниц не зависели от реализации задачи. Я буду использовать DataTemplates, у которых целевой тип будет назначен определенному типу задачи. Таким образом, пользовательский интерфейс может оставаться слабо связанным, а мои модели представления не тесно связаны со всеми моими репозиториями или реализациями.

Спасибо за любую помощь.

Джонатон


person Johnathon Sullinger    schedule 22.06.2014    source источник


Ответы (1)


Зарегистрируйте реализации, а не фабрику. Модель представления никогда не должна касаться репозитория. Контроллер использует репозиторий для получения или обновления модели и предоставляет ее модели представления.

person Adrian Booth    schedule 22.06.2014
comment
Под контроллером я предполагаю, что вы ссылаетесь на mvc? Я использую mvvm и WPF. Это имеет значение? - person Johnathon Sullinger; 22.06.2014
comment
Ни один mvvm не выигрывает от контроллера. Лучшая реализация mvvm, которую я нашел, — это модель => бизнес-объект, контроллер заполняет модель представления командой и начальными значениями и т. д. Модель представления — это только то, что нужно пользовательскому интерфейсу, то есть коллекции данных и команд для кнопок. Контроллеры не нужны, но они помогают повторно использовать код. Я предполагаю, что будет несколько представлений, в которых вы видите один и тот же объект. Наличие контроллера, обеспечивающего одну и ту же команду для каждого, снижает усилия по тестированию и кодированию. - person Adrian Booth; 22.06.2014
comment
Ваш класс контроллера будет создавать команды делегата, передавая им рабочий объект, такой как элемент обновления на контроллере, и метод, который определяет, когда команда активна. - person Adrian Booth; 22.06.2014
comment
Все еще не уверен, что я следую извините. Представление привязано к модели представления, имеет ли виртуальная машина ссылку на объект контроллера? - person Johnathon Sullinger; 22.06.2014
comment
Нет, я бы ссылался на виртуальную машину с контроллера. Создайте экземпляр желаемой виртуальной машины из контроллера, передав необходимые элементы в конструкторе. - person Adrian Booth; 22.06.2014
comment
Но это работает против Prism, который занимается подключением виртуальной машины к соответствующему представлению, не так ли? - person Johnathon Sullinger; 22.06.2014