Здравствуйте, AndrewVK, Вы писали:
S>>Покажите на этом примере как правильно.
AVK>Ничего не знаю про Unity, поэтому не покажу.
В данном примере в Unity делаете регистрацию:
container.RegisterType<IFileService, TestFileService>();
А потом, когда требуется инстанс, пишите:
container.Resolve<IFileService>();
и получаете тот, который ранее зарегистрировали.
У меня парадигма такая:
1. Сначала пишутся контракты (interface) сервисов и бизнес-сущности (можно было бы тоже interface, но для простоты просто классы, т.к. там только поля).
2. Потом параллельно делается внедрение этих контрактов в рабочую библиотеку с тестовыми реализациями и одновременно их реализация (может разными людьми).
3. Замена тестовых заглушек на реальные происходит через Unity, т.е. в рабочем коде ничего изменять не нужно (только переконфигурировать все в 1 месте (там где RegisterType)).
Т.е. разработка начинается с контракта.
Нужно для распараллеливания процесса разработки, структуризации проекта и для упрощения тестирования.
И вот у меня дилемма с настройками в примере выше. Включать ли в контракты сведения о настройках. Дело в том что они желательны для тестирования, т.к. тестовые заглушки всегда отдают валидные данных (хоть и ничего не значащие) а от настроек зависит их валидность. Т.е. желательно бы настройки определить в контрактах.
Варианты такие:
1. Оставить метод Init(Settings settings). Тогда он берет на себя роль конструктора. Как бы ничего, но доп. проверки и нужно не забывать его вызывать.
2. Оставить в библиотеке контрактов класс Settings, но никак не отображать инициализацию в контрактах (т.е. убрать метод Init(Settings settings)). Тогда можно задействовать конструктор и фичу Unity InjectionConstructor. Можно создавать экземпляр класса через Unity Resolve<IFileService> и передавать нужное значение в конструктор. Тут проблема -- нужно не забывать передавать этот InjectionConstructor а так же требуется чтобы во всех реализациях интерфейса был конструктор с нужным параметром (просто помнить -- никакой подсказки от компилятора не будет).
3. Фабричный метод который тут предлагали. Если я правильно понял, предлагается создать некий IFileServiceFactory с методом CreateFileService(Settings settings) а потом еще и реализацию для него. Реализацию так же получать через Unity, к примеру. Однако же в таком случае нужно помнить что TestFileService/FileService нельзя создавать вручную -- только через реализацию IFileServiceFactory. И не ясно чем это так уж лучше Init.