Под зависимостями вы имеете в виду связанные внешние отношения в БД? В юзингах вы можете юзать совершенно что угодно, это просто синтаксический сахар над 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, выглядеть будет почти так же, но зато работать именно так, как и предполагается.
Я не говорил, что это не будет работать. Но не все то что работает, написано хорошо. Как дизайнер вы должны это понимать.
Дмитрий Ковальский: берем два часа (очень условного минимального функционала) и умножаем их на два - с тестированием, пропущенными кейсами которые потом выливаются в какой-нибудь глупый баг. Правильно про костыли напомнили, еще и с костылями. Чисто интерфейсные задачи иной раз куда важнее тех, которые не касаются интерфейса вовсе - поскольку пользователь взаимодействует только с интерфейсом. Впрочем, вашу позицию понял, просто вопрос не о том, стоит ли писать самому, а о том, где найти. И вы ответа не дали.
Я раньше тоже любил писать свое, а потом покрывать это тестами изо всех сил, и потом еще на гитхаб штоб. Написать свое я могу, не вопрос, но зачем, если есть готовое?
Тарас Лабяк: как вы этот вывод сделали-то? Я изначально написал о том, что меня смущает реализация наследования в JS через процедуру. Мне кажется, лучше создать какой-то базовый объект-прототип и реализовать в нем метод extend и все дальнейшие "классы" наследовать от него. Это более ООП-подход.