МСУskyANAА если ты курсы валют начал брать из своей БД, то ты методы IDataService3 добавляешь в IDataService1, реализуешь.
Везде в коде заменяешь обращение к первому на обращение к последнему и выкидываешь IDataService3?
Конечно нет. Если меняется источник курсов, пишется новый сервис NewDataService, унаследованный от OldDataService (OldDataService: IDataService3) и правлю необходимые методы через override. Соотвественно, программа как работала с курсами по протоколу IDataService3, так и работает. Протокол менять нельзя, можно менять реализацию.Старый инстанс IDataService1 и новый инстанс IDataService3 будут использовать один и тотже EF репозиторий?

МСУskyANAМСУ, допустим мы пишем систему онлайн бронирования отелей и авиаперелётов.
а. Ты реализуешь IHotelService для поиска отелей, IAirflightService для поиска авиаперелётов и IBookingService для бронирования найденного набора услуг, или...
б. Ты реализуешь один IDataService для и для поиска отелей и перелётов, и для бронирования найденного набора услуг?
Если работа с отелями, перелетами и бронированиями ведется прозрачно и с одной БД или несколькими БД одного сервера, то скорее всего я не буду разделяться на несколько сервисов и напишу один IDataService.Завтра тебе надо будет интегрироваться с различными мировыми системами поиска и бронирования, с системами партнёров и т.п. Причём одни предоставляют только поиск и бронирование отелей, другие только перелётов, третьи только прокат авто, четвёртые предоставляют всё что есть у тебя плюс ещё какие-нибудь экскурсии и трансферы, и что ты будешь делать?

Как ты будешь реализовывать IDataService для поставщика, предоставляющего только отели? Методы, что относятся к другим классам услуг, будут кидать NotImplementedException?

МСУskyANAСтарый инстанс IDataService1 и новый инстанс IDataService3 будут использовать один и тотже EF репозиторий?
Не обязательно. То есть разные сервисы используют разные EF репозитории? Или когда тебе хочется, то ты используешь один EF репозиторий в разных сервисах? Тогда покажи как ты это делаешь.
МСУНо лучше под один (или несколько) EF контекстов делать IDataService, а не наоборот.Сам себе противоречишь:МСУskyANAА если ты курсы валют начал брать из своей БД, то ты методы IDataService3 добавляешь в IDataService1, реализуешь.
Везде в коде заменяешь обращение к первому на обращение к последнему и выкидываешь IDataService3?
Конечно нет.

МСУskyANAЗавтра тебе надо будет интегрироваться с различными мировыми системами поиска и бронирования, с системами партнёров и т.п. Причём одни предоставляют только поиск и бронирование отелей, другие только перелётов, третьи только прокат авто, четвёртые предоставляют всё что есть у тебя плюс ещё какие-нибудь экскурсии и трансферы, и что ты будешь делать?
Отлично, я пишу новый NewDataService, унаследованный от того же IDataService или от предыдущего OldDataService (который так же наследуется от IDataService). В моем NewDataService закладывается интеграция различными мировыми системами поиска и бронирования, с системами партнёров и т.п. NewDataService так же легко стыкуется с моим приложением, которое умеет работать с IDataService. Вся черная работа лежит в black box - в NewDataService.

skyANAКак ты будешь реализовывать IDataService для поставщика, предоставляющего только отели? Методы, что относятся к другим классам услуг, будут кидать NotImplementedException?
Не понял тебя. IDataService работает не только с отелями, а объединяет в себе работу как с отелями, так и с бронированием и прочим. В чем проблема-то? Если ты разносишь работу на несколько зон отвественности (IDataService1, IDataService2, IDataService3), значит твое приложение умеет работать только с этими зонами. Отстыкуй любой блок и пристыкуй новый (был OldDataService2, стал NewDataService2) - и всё у тебя будет роаботать.Хорошо, пойдём с другой стороны :)
Есть поставщики, что предоставляют функционал поиска и бронирования только авиаперелётов: IAirflightService.
Есть поставщики только отелей: IHotelService.
Есть поставщики только трансфер: ITransferService.
И твой NewDataService круто с ними работает, вернее тупо пробрасывает запросы им.

То есть в твоей системе есть и IAirflightService, и IHotelService, и ITransferService, и IDataService.
Заметь кстати, что OldDataService, что работает с твоей БД, теперь обязан каким-то образом реализовать поиск и бронирование трансферов, которых нет в твоей системе

МСУskyANA, главный плюс такого подхода в легкости управления проектом.
1. Вот я беру и на аутсорс тебе выношу задачу - написать слой, который будет работать с отелями, перелетами и бронированиями через какие-то там внешние сервисы.
2. Отправляю тебе только DLL с требуемым IDataService и классами-болванками для резултатов методов IDataService. Всё. Тебе ничего не надо знать о моем приложении, ты просто решаешь свою задачу независимо.
3. Я продолжаю дальше разработку по проекту, вкорячив фейковую реализацию IDataService.
4. При приемке решения от тебя я выкидываю свой фейковый датасервис и вставляю твой - отлично, моё приложение теперь интегрировано с мировыми отелями, перелетами и бронированиями.В реальности ты такое не сможешь сделать.
С мировыми отелями, перелетами и бронированиями нужно будет заключить контракт, чтобы интегрироваться.
Хотел бы я посмотреть как ты это сделаешь одновременно.

В реальности поставщики подключаются отдельно. То есть по мере необходимости подключения всё новых поставщиков, тебе придётся допиливать сервис, компилировать, тестировать. В особенности это будет весело, при подключение поставщиков услуг, которых у тебя раньше не было.

По мне так проще реализовать конкретный IAirflightService, или набор сервисов, протестировать их и подключить в систему.

МСУ, ну то есть мы пришли к тому, что в системе должны быть отдельные сервисы: IAirflightService, IHotelService, - так?
Не смотря на то, что в начале работа с отелями, перелетами и бронированиями ведется прозрачно и с одной БД?

МСУskyANAВ реальности ты такое не сможешь сделать.
С мировыми отелями, перелетами и бронированиями нужно будет заключить контракт, чтобы интегрироваться.
Хотел бы я посмотреть как ты это сделаешь одновременно.
Это не мои проблемы, а заказчика ПО - пусть договариается, покупает лицензии, заключает контракты. Главное, что инфраструктурно и логически у меня не будет ниаких проблем переключиться на другие источники, хранилища и сервисы. И пусть не одновременно, а поочереди - не суть, у меня всё будет работать так же бесперебойно как и раньше.

skyANAВ реальности поставщики подключаются отдельно. То есть по мере необходимости подключения всё новых поставщиков, тебе придётся допиливать сервис, компилировать, тестировать. В особенности это будет весело, при подключение поставщиков услуг, которых у тебя раньше не было.
Допиливать не придется, это будет новый датасервис с новым источником. Причем, если большая часть его реализации совпадает со старым, достаточно будет просто от него отнаследоваться. Если вдруг потребуется вернуться к начальному датасервису, я всегда смогу это сделать.

skyANAПо мне так проще реализовать конкретный IAirflightService, или набор сервисов, протестировать их и подключить в систему.
Я тебе не понимаю. А у меня что, не так? Либо пихай всё в один ISuperService, либо разноси на несколько. От перемены мест стлагаемых сумма не изменяется. В чем проблема-то?

skyANAМСУ, ну то есть мы пришли к тому, что в системе должны быть отдельные сервисы: IAirflightService, IHotelService, - так?
Мы к этому не приходили. Я с самого начала сказал, что может быть один общий датасервис, либо несколько, о которых ты пишешь. Принципиальной разницы тут нет.

skyANAНе смотря на то, что в начале работа с отелями, перелетами и бронированиями ведется прозрачно и с одной БД?
Тоже уже отвечал на эту тему - ограничений никаких нет. Определяй зоны ответственности по усмотрению, главное архитектурный принцип стыковки слоёв не нарушается.Бла-бла-бла, ни читать, ни думать ты не хочешь

МСУ, ещё раз.
Изначально у тебя своя система (со своей БД), что позволяет искать и бронировать отели и перелёты.
Ты предложил сделать один сервис:
Так?

МСУskyANAТак?
Верно мыслишь, человече.Круто. Приходит время интеграции: заказчик говорит, что нужно подключить поставщика отелей Travko, через их XML API.
Что ты делаешь, о гуру-архитектор? NewDataService : OldDataService и новый IHotelService и его реализацию для Travko?

МСУ, приложение у тебя как работало с IDataService так и продолжает с ним работать.
Как ты реализуешь работу с Travko?

То есть теперь поиск проживания в отеле должен вестись и в твоей системе, и в подключённом поставщике Travko.

МСУ, тупишь ты, я разбираю твой подход.
Реализация метода Find() для поиска в твоей системе как я понимаю юзает EF репозиторий.
Как ты засунешь туда работу с XML API Travko?