Здравствуйте, 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.

Здравствуйте, 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.