Это оптимальный вариант, учитывающий даже случай если они будут разного размера.

Вдруг. ?

Мой вариант более базовый. Не всегда есть возможность в коде задать тип, иногда есть только Type. А вот typeof всегда можно сделать. Ну а поверх моего варианта уже можно написать вариант с генериком если надо. Одна строка, вызывающая мой метод.

эээ, это как интересно, если в твоём примере кода доступен тип MyModel - мы можем его заюзать в генерик-методе запросто другой вопрос, что у него может не быть конструктора по-умолчанию... но... лолшто, модели без дефолтных конструкторов?

если они точно фиксированные, можно немного ускорить выполнение что бы не делать полный проход ? var count = dict.First(pair => pair.Value.Length);

ну в целом да

если они точно фиксированные, можно немного ускорить выполнение что бы не делать полный проход ? var count = dict.First(pair => pair.Value.Length);

Да делай ты как хочешь на здоровье. Это я так, люблю доводить до идеала.

Так сказать унифицировать.

да мне это вообще не надо. По мне идеально когда код работает максимально быстро. У тебя свои идеалы. Не смею больше беспокоить )

эээ, это как интересно, если в твоём примере кода доступен тип MyModel - мы можем его заюзать в генерик-методе запросто другой вопрос, что у него может не быть конструктора по-умолчанию... но... лолшто, модели без дефолтных конструкторов?

Ну само собой. Тут уже ответственность на вызывающем метод коде. Не надо туда передавать модель без конструктора.

эээ, это как интересно, если в твоём примере кода доступен тип MyModel - мы можем его заюзать в генерик-методе запросто другой вопрос, что у него может не быть конструктора по-умолчанию... но... лолшто, модели без дефолтных конструкторов?

В шарпе в блоке удобна инициализировать, даже если конструктора нет. Прикольно, мне такого не хватает

Да, вот только вариант с ограничением new() на уровне генерик-метода в случае отсутствия конструктора без параметров сфейлится на этапе компиляции и пошлёт всех лесом, а в случае использования Type и метода Activator.CreateInstance(type) - смачно шлёпнется во время выполнения. Поэтому - имхо - первый вариант надёжнее.

вчера был вопросик, как определить еслть ли в бд уже обект

List<long> Id_db = (db.Users.Select(ie => ie.pk)).ToList(); userName = userName.Where(x => !Id_db.Contains(x.pk)).Select(x => x).ToList();

решил вот так

т.е. сначала выгружаются все ид из бд

и справнивается с моим списком

едрическая сила

но мне кажется что это не очень хорошее решение

мб есть решение поудобнее что ли?

List<long> Id_db = (db.Users.Select(ie => ie.pk)).ToList(); userName = userName.Where(x => !Id_db.Contains(x.pk)).Select(x => x).ToList();

FirstOrDefault

long userID = 100500L; bool exists = db.Users.Any(user => user.Id == userID);

Да, эни если узнать есть,нет

да этого вполне достаточно

просто знать есть или нет

я смотрел в сторону find там вроде как ищет по базе тоже

как вариант

Тебя эни чем не устроил?

тем что я про него не знал)) теперь буду знать, спасибо за помощ

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

тем что я про него не знал)) теперь буду знать, спасибо за помощ

using System.Linq; жи

да вот я ток вчера ее первый раз пощупал, не знаю еще всех ее возможностей...

"целиком отказался от вара" « религия какая то

да вот я ток вчера ее первый раз пощупал, не знаю еще всех ее возможностей...

Ты потом еще посмотри naming conventions. У тебя названия полей сущностей какие-то не очень

Ты потом еще посмотри naming conventions. У тебя названия полей сущностей какие-то не очень

это такие сущности мне сервер отдает, я нестал переименновывать сразу, а сейчас уже привык

"целиком отказался от вара" « религия какая то

я бы назвал это вкусовщиной

Ну на сервере же ты структуру создаешь, не?

не

Ну ок

я бы назвал это вкусовщиной

+ тоже стараюсь использовать var по минимуму явное написание имени типа как-то дисциплинирует, что ли, и упрощает понимание кода другими разработчиками

а если вокруг этой красоты ещё и тесты хорошие, годные накручены - вообще песня

Скажите, а EF достаточно умен, строит нормальные запросы к бд? А то я привык все руками писать, учитывая план выполнения и данные, которые нужны. Просто выглядит удобно, конечно, пишешь себе обычный linq и работает. Но насколько оптимально?

а если вокруг этой красоты ещё и тесты хорошие, годные накручены - вообще песня

Иди обниму, бро (нот гей)

Дисциплинирует? Какой ужас...

Скажите, а EF достаточно умен, строит нормальные запросы к бд? А то я привык все руками писать, учитывая план выполнения и данные, которые нужны. Просто выглядит удобно, конечно, пишешь себе обычный linq и работает. Но насколько оптимально?

зависит от запроса. иногда очень стремно, но всегда можно ручками запрос написать и сказать ЕФ использовать его и только его

"целиком отказался от вара" « религия какая то

У нас это код стайл, например. И по мне, хоть и длиннее все получается, но гораздо нагляднее.

Вы ещё и this пишите небось?

Нет, зачем?

Нагляднее же

Это почему?

Если переменная объявлена с конструктором или литералом, то в явном объявлении типа смысла нет, с другой стороны читабельности коду это не прибавляет а только зашумляет код

+ тоже стараюсь использовать var по минимуму явное написание имени типа как-то дисциплинирует, что ли, и упрощает понимание кода другими разработчиками

Все бы вам кода лишнего пописать, индусы.

Если переменная объявлена с конструктором или литералом, то в явном объявлении типа смысла нет, с другой стороны читабельности коду это не прибавляет а только зашумляет код

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

Все бы вам кода лишнего пописать, индусы.

давай, научи как надо

давай, научи как надо

let array = [Entity]

Но конечно можно и let array : Array<Entity> = Array<Entity>()

Но это же не тот чат. Или свифтокодеры хвастают своей религией везде, где только можно? ?

Но это же не тот чат. Или свифтокодеры хвастают своей религией везде, где только можно? ?

Вроде еще в джаве можно даймонд оператор без указания типа юзать при инициализации

Родина вам дала вар. Нет, не хочу. Хочу писать типы

var xx = GetSomething();

давай, определяй тип

можно конечно навести мышкой, потупить, и посмотреть в попапе

Конечно можно

И из контекста и названия обычно и так все понятно

Сингл класс сингл респонсабилити

Все такое

ERROR: S client not available

В фантазиях да, а в реальности бывает и нет

как проще всего указать что данные в столбце бд должны быть уникальными?

в конструкторе вижуал ток первичный ключ можно задать, а там же вроде еще какие то ключи есть, вроде как они за это овтечают

Но конечно можно и let array : Array<Entity> = Array<Entity>()

> это убогое двоеточие > повторение типа два раза

как проще всего указать что данные в столбце бд должны быть уникальными?

Смотри, Макс, вот прям ответ на вопрос: ALTER TABLE MyTable ADD CONSTRAINT uc_myConstr UNIQUE (MyColumn) GO

блин думал работа с базой усорит программу, а оказалось чтопроверить 200 строка на то есть ли они в листе куда быстрее чем проверить есть ли они в базе на 3к объектов....

Смотри, Макс, вот прям ответ на вопрос: ALTER TABLE MyTable ADD CONSTRAINT uc_myConstr UNIQUE (MyColumn) GO

спасибо

блин думал работа с базой усорит программу, а оказалось чтопроверить 200 строка на то есть ли они в листе куда быстрее чем проверить есть ли они в базе на 3к объектов....

ты их по одной строке перебираешь и сравниваешь небось?

через any

код покаж

не ну как, конечно берет список и по одной строке делает запрос

using (BlackListUser db = new BlackListUser()) { List<User> tmp = new List<User?); foreach (User user in userName) { if (!db.Users.Any(user_ => user_.pk == user.pk)) tmp.Add(user); } userName = tmp; }

как то так

не надо так делать

надо один раз в БД спросить есть ли у нее группа айдишников, а не на каждый айдишник

List<long> Id_db = (db.Users.Select(ie => ie.pk)).ToList(); userName = userName.Where(x => !Id_db.Contains(x.pk)).Select(x => x).ToList();

было вот так

но мне казалось это не правильно

хотя на практике работало оно куда быстрее чем то что сейчас

В фантазиях да, а в реальности бывает и нет

Ну могу сказать что живу в карманной сказке

в начально варианте идет 1 запрос на столбец ид и потом уже сверяет

получается меьнше запросов, если я правильно понимаю работу селект

получается меьнше запросов, если я правильно понимаю работу селект

скорее всего не правильно понимаешь. селект в linq не то же самое что селект в sql

List<long> Id_db = (db.Users.Select(ie => ie.pk)).ToList(); userName = userName.Where(x => !Id_db.Contains(x.pk)).Select(x => x).ToList();

плес забудь с++ молю

а что не так7

Могу даж за тебя свечку поставить в храме, только забудь этот нейминг

аа

не id_db

а databaseId

или что-то такое

камелкейс там

и паскалькейс