Под зависимостями вы имеете в виду связанные внешние отношения в БД? В юзингах вы можете юзать совершенно что угодно, это просто синтаксический сахар над try {} finally { Dispose }.
Where в данной ситуации (работа с EF) возвращает `IQueryable`, но затем вы вызываете метод GroupBy, который возвращает `IQueryable>`, который уже к `IEnumerable` не приведется.
Если вы хотите возвращать группированные значения, то тогда у вас должен быть корректный контракт вашего API, например `IDictionary>`, тогда ваш код может выглядеть так:
Или если контракт метода корректный и группировка вам не нужна, то тогда достаточно `return db.Orders.Where(x => x.Kod == kod).ToList();`
Также обратите внимание на два пункта:
1. Обращение к базе данных прямо из контроллера считается дурным тоном. Вы огребете массу проблем, дублирования кода и прочего в будущем. Попробуйте воспользоваться паттерном Repository.
2. Раз это dotnet core, то вы можете очень удобно пользоваться асинхронными операциями, а то кому нужны дедлоки? Почитайте про async контроллеры.
konstantinborodov: я, уж извините, вам не верю. Ваш вопрос и ваши комментарии выдают в вас очень начинающего как фронта, так и программиста. Впрочем, самоустраняюсь из беседы.
konstantinborodov: позволю себе еще добавить по вашим комментариям.
Во-первых, если h1 - это высота, то лучше так и написать же, height, будет гораздо понятнее. Такие сокращения - это экономия на спичках, ни к чему хорошему не приведет.
Во-вторых, идентификаторы предполагаются уникальными не просто так; движок рендера строит индекс, как правило B-tree. Когда вы добавляете два одинаковых идентификатора, вы очень сильно замедляете поиск по DOM, либо делаете его в принципе невалидным. Смотрите, вы по сути находите все свои элементы с идентификаторами, пользуясь менее быстрым индексом по значениям аттрибутов, а затем по каждому найденному элементу пробегаете весь путь до корневого элемента в поисках "родительского" идентификатора. То есть вы реально делаете адское количество проверок и поисков против logN прохода по индексу.
Если вы намерены использовать все это именно таким макаром, то тогда вам лучше воспользоваться аттрибутом class, а не id, выглядеть будет почти так же, но зато работать именно так, как и предполагается.
Я не говорил, что это не будет работать. Но не все то что работает, написано хорошо. Как дизайнер вы должны это понимать.
function MyClass(prop) {
var myProp = null;
init(prop);
function myMethod() {
return myProp;
}
function init(prop) {
myProp = prop;
}
return {
myMethor: myMethod
}
}
Только представьте, что это масштабировано на 10+ методов/пропертей, каждый из которых этак в 50 строк кода, и в сумме получается до тысячи строк вот этого даже не знаю как обозвать.
Борис Животное: ну собственно для души дома есть свой проект, конечно, но хочется же на работу ходить как на праздник, чтоб повсюду уместные паттерны, ревью и парная работа, а сверху тдд еще... Эх.
Не, там реально js очень очень очень сумасбродный. Я сколько лет фронтендером живу, такой жести еще не видал. Но есть еще один недостаток этого подхода - это очень старый, очень продакшеновый и очень масштабный проект, он на мировом рынке второй по охвату (хоть и с сильным отставанием от первого места). Каждый день по крупице, это лет двадцать уйдет. С учетом постоянных поставок нового чудо-кода =).
Ну диверсии не пройдут, ибо менеджеры бдят за коммитами и могут наехать в духе "работал на деньги заказчика в рабочее время, а занимался каким-то рефакторингом". Может быть, есть положительный опыт убеждения заказчика в том, что рефакторинг ему прибылен?
Ну вообще в любом нормальном проекте деплой должен быть автоматизирован, и верстальщику должно быть достаточно установить компоненты и запустить батник там или шелскрипт или что-нибудь между.