МСУmonstrUкак то это switch напрашивается на замену (типа фабрики ?) - что, при необходимости подключения еще 10 провайдеров надо расширять этот switch и переписывать AirflightCondition ?
А это не принципиально уже, хочешь отвязаться от AirflightCondition, кури просто строковый параметр ProviderName, по нему из конфигурации (БД, XML, конфиги и т.д.) вытягивай провайдера и запрашивай через него IEnumerable<Airflight>.

monstrUхрупкое решение - изменение в поставщике требует перекомпиляцию проекта.
Не хрупкое, идет речь о принципе ответственности, а не о том, как гибко одной ложкой зачерпнуть все провайдеры. По-быстрому - через AirflightCondition, по-уму - описать все провайдеры и способ доступа к ним в конфиге.

skyANAМСУ, а теперь моя реализация ...
При подключении нового поставщика, мы тупо пишем реализацию для поставщика (или отдаём это на аутсорс), регистрируем поставщика в приложении и всё!
Никаких 5 методов из 50 вообще переписывать не надо, никаких NewDataService не надо!
Те же яйца только с боку. Выше я описал примерно такой же способ.

skyANAГораздо гибче, чем у тебя с твоим switch в методе Find() и постоянным переписыванием IDataService.
Ты не зришь в корень, switch - не панацея, это решение в лоб. Если нужно динамически подлить все провайдеры, ты их подгружаешь (регистрация) в том же IDataService. Речь не о том, как красиво собрать все провайдеры :)

skyANAПричём MVC приложение может работать как во твоему принципу, так и через инъекции конкретного сервиса в конкретный контроллер
В топку инъекции конкретного сервиса в конкретный контроллер, пусть инстансами управляет базовый.

skyANAСмотрите-ка, ты по тихому добавил некий IHotelSearcher. А я тебе намекал на то, что он появится.
Не суть, ты мне главное верни IEnumerable<Airflight>, а я сам разберусь, как его компактнее упаковать и зарегистрировать.

skyANAИ какой на фиг return внутри case? Нужно по всем поставщикам искать. Но это уже молочь.
Гы, добавь в енум AirflightProvider флажок All и ищи по всем :)

Славная привычка к говнокоду дает о себе знать.
Засовываем все в кучу: под двадцать сервисов с 10-20 методами в каждом , обвешиваем все это счастье атрибутами и кучей параметров из конфига. Это даже в канализации не поплывет, а сразу утонет. На пяти сервисах уже надорвешься.
Полный бред.

skyANA, пустое это занятие, что-то втолковать ему.

МСУSeVaПро принцип единичной ответственности эта чурка даже не слышала.
Одна из причин для чего нужны обобщенные контроллеры - это, если вдруг на проекте попадется такое ...(не буду уточнять), то будет возможность держать его на коротком поводке, чтобы он кизяками все вокруг не закидал.
Принцип единичной ответственности как-раз реализует датасервис, просто скудность твоего больного воображения не позволяет понять это. Неуч, ASP.NET MVC не умеет работать с обобщенными контроллерами, все остальные жалкие потуги скрестить ужа с удавом приводят к гавнокоду, который никому не нужен.

SeVaЧто вы с ним этот идиотизм обсуждаете? У него никогда не было этих контроллеров и не будет, чисто теоретический бред.
Учи матчасть, бестолочь.

Учить матчать не буду советовать. Все равно ничего не поймешь.
1. В asp.net mvc все на интерфейсах с той же единичной ответственностью и можно безболезненно заменить любую часть.
Для этого достаточно переопределить ControllerFactory. тынц .
Реализация дубовая с switch, специально чтобы ты хотя бы что-то понял. В нормальном варианте необходимо использовать di контейнеры, но ты их не осилил и не осилишь.

2. Просто поражает твоя поразительная способность все воспринимать через одно место. Принцип единичной ответственности означает, что причина изменения класса может быть только одна, а не один тупой сервис на все случаи жизни.


Эти принципы выработаны теми, кто уже набил шишки и наелся дерьма, которое ты предлагаешь.

МСУSeVaСлавная привычка к говнокоду дает о себе знать.
Весьма странно слышать это от обезьяны-наколеночника.

SeVaЗасовываем все в кучу: под двадцать сервисов с 10-20 методами в каждом , обвешиваем все это счастье атрибутами и кучей параметров из конфига. Это даже в канализации не поплывет, а сразу утонет. На пяти сервисах уже надорвешься.
Полный бред.
Остается только понять, откуда тут взялись атрибуты, двадцать сервисов и что там у тебя за куча. Иди букварь читай про генерик контроллеры в MVC, балбес.

SeVaskyANA, пустое это занятие, что-то втолковать ему.
Иди зад чини от синяков в ветке про пул потоков.

У нас в проекте больше. ПОка ты в обработчиках ковырялся, а не один проект сделал на обобщенных классах.
С ними даже с такими как ты можно их делать, в срок и без дерьма, которое ты тут рисуешь

Мудафаил, ты простой му**к и говнокодер, который с толстой задницей и кучей switch может быть и сможет сделать одну портянку на сотни методов, но это дерьмо быстро выкинут в помойку, когда пойдут изменения требований и начнется самое интересное.
И не тебе муфлону судить о том, что хорошо или плохо. Твое дело копать, если рискнут дать лопату.