alesto: Разницы нет?? Шутите чтоли... За каким чертом вы будете сохранять всякий мусор, если планируете постоянно его выковыривать в последствии при выводе? Одно дело когда вы хотите экранировать эти элементы и выводить, но вы вроде хотите удалять.
Andrey Dyrkov: Сделайте Publish каждого проекта и увидите что ваше приложение это не 3 dll файла, а малость побольше. Если создадите на серваке 2 разных приложения в IIS - все будет тихо и мирно паралельно работать.
Илья: Сервак в любом случае может исполнить эти 2 запроса одинаково, так как развернет его в идентичные инструкции. Однако когда вы будете вносить изменения - то нужно делать тесты производительности
Илья: По большому счету разницы никакой. Они делают примерно тоже самое. Дело в том что время выполнения запроса может разниться, а если вы собираете статистику по группам(используете агрегатные функции) то нужно использовать GROUP BY . Смотрите Query Plan и время исполнения запроса.
VigVam: Вы написали большую длинную LINQ структуру которая развернется черт знает в какой скрипт на базу. Хотите просто, быстро и надежно - пишите хранимку которая на вход принимает ChampionatId и возвращает набор данных MatchId,Home,Guest. Не полагайтесь на EF. Если всеже вам хочется - напишите в несколько инструкций получение всех нужных вам данных - не в одну строку, а в несколько. А затем через отладку спокойно смотрите что в эти выборки попадает и как проходят проверки.
1) Это пишут или в комментариях к ответу(я совершенно случайно заметил вашу запись) Или в вопросе с меткой обновления.
2) Ваш второй код банально неверен. CommandId может быть 112, а HomeId = 1,2,11,12,112 и все пройдут проверку на Contains, хотя это неправильно.
Sushkov: создайте 1 объект вне цикла, а не создавайте раз за разом. Тоже самое с проверкой directoryinfo - путь не меняется, а проверяете вы раз за разом.
ZubSam: А реальный проект никогда не замкнется на одной веб-апликухе. Всегда будут различные слои и компоненты. Есть источник данных - база, а кто и как в нее пишет/читает - уже отдельная песня и набор архитектурных решений. Будет у вас отдельный компонент для работы с данными и разные клиенты, работающие с этим компонентом. Или еще каким-либо способом это реализуете.