Допустим у нас есть таблица Table с полями C1, C2, C3, C4, C5

И есть класс

class TableClass
{
  public string C1{get;set;}
  public string C2{get;set;}
  public string C3{get;set;}
  public string C4{get;set;}
  public string C5{get;set;}
}

И допустим у нас есть процедура GetFirstRow, которая возвращает первую строчку таблицы Table, но не все поля, а только C1, C2, C3
Ниже приведён код с ошибкой, т.к. при такой записи необходимо чтобы процедура GetFirstRow возвращала все 5 полей!

                using (DataBaseContext db = new DataBaseContext ())
                {
                    TableClass row = db.Database.SqlQuery<TableClass>("GetFirstRow").FirstOrDefault();
                }

Как можно сделать так чтобы вышеописанный пример заработал? Причем не меняя содержимое класса TableClass заработал и такой пример:

                using (DataBaseContext db = new DataBaseContext ())
                {
                    TableClass row = db.Database.SqlQuery<TableClass>("GetFULLFirstRow").FirstOrDefault();
                }

Где GetFULLFirstRow возвращает все 5 полей таблицы!!!

Здравствуйте, SanyaVB, Вы писали:
SVB>И допустим у нас есть процедура GetFirstRow, которая возвращает первую строчку таблицы Table, но не все поля, а только C1, C2, C3

var row = db.Set<TableClass>().Select(x => new { x.C1, x.C2, x.C3 }).FirstOrDefault();

SVB>Где GetFULLFirstRow возвращает все 5 полей таблицы!!!

var fullRow = db.Set<TableClass>().FirstOrDefault();

P.S. Если у вас процедуры, то зачем Entity Framework?

Здравствуйте, QrystaL, Вы писали:

QL>P.S. Если у вас процедуры, то зачем Entity Framework?

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

1) Иногда не все (в частности производительности) можно сделать простым функционалом EF, именно поэтому в EF добавили функционал вызова собственного запроса!
2) EF примечателен тем, что в нем заложен механизм преобразования полученных данных в объект (или наоборот). Раньше приходилось писать это все в ручную... много рутинной работы

ОТВЕТ: нет желания тянуть EF и старый добрый SQL провайдер

Здравствуйте, SanyaVB, Вы писали:

SVB>1) Иногда не все (в частности производительности) можно сделать простым функционалом EF, именно поэтому в EF добавили функционал вызова собственного запроса!
SVB>2) EF примечателен тем, что в нем заложен механизм преобразования полученных данных в объект (или наоборот). Раньше приходилось писать это все в ручную... много рутинной работы

SVB>ОТВЕТ: нет желания тянуть EF и старый добрый SQL провайдер

EF примечателен тем, что предоставляет набор верёвочек для того, чтобы отвязать сервер от клиента.
Если нужен просто маппер данных то и используйте маппер данных — их полно разных.

Здравствуйте, TK, Вы писали:

TK>EF примечателен тем, что предоставляет набор верёвочек для того, чтобы отвязать сервер от клиента.
TK>Если нужен просто маппер данных то и используйте маппер данных — их полно разных.

А если нужны верёвочки и мапер??? нужно использовать 2 технологии?
Тут речь идет именно об этом! Нет желания тянуть 2(или более технологии) и не хочется останавливаться на одной технологии, а именно на обычном SQL провайдере исключая EF, т.к. на нем много чего завязано.

Для решения вопроса я сделал грабли: создал базовый класс и от него наследовал другой класс, который был для него расширением. Задача решилась, но блин!!!! Это не правильно! Допустим у нас в БД 10 полей и нам потребуется использовать всевозможные комбинации полей как результат SELECT. Простая комбинаторика 10!/ 4! — это для случая 4 полей. Ну и что??? 27 млн классов создавать? Я понимаю что это теория... и в жизни нам необходимо всего лишь 2-4 возможный результата SELECT, НО!!! Придумывать название классов для одинаковых по существу данных — это БРЕД! Когда можно просто неиспользуемые поля присвоить значение по умолчание(например NULL)

И вопрос мой был тут написан именно потому что я предполагаю что EF это все реализует, а как??? я этого не знаю молчит Вот обращаюсь с вопросом КАК к знающим людям!
Скажу честно! Удивлюсь если в EF это не заложено!!!

Здравствуйте, SanyaVB, Вы писали:

SVB>Скажу честно! Удивлюсь если в EF это не заложено!!!
Сразу скажу, не спец и не фанат EF, но насколько я знаю:
В EF заложено умение извлекать только нужные поля в зависимости от запрошенной проекции (т.е. перечисленных в селекте полей). Для себя я сделал вывод, что эту фишку сложно использовать на практике, поскольку проекция отделена от EF несколькими слоями и протащить метаданные об использовании к месту извлечения как-то сложно. Поэтому для себя я всегда ограничивался созданием пары версий классов (light и full), которые удовлетворяли мои нужды. "Иметь в некоторых случаях null в полях", мне кажется стабильным источником для багов.

Плюс в EF есть возможность ленивой загрузки и явной загрузки. В сочетании с парой классов — вполне рабочая схема вырисовывается.

Здравствуйте, Neco, Вы писали:

N>Здравствуйте, SanyaVB, Вы писали:

SVB>>Скажу честно! Удивлюсь если в EF это не заложено!!!
N> "Иметь в некоторых случаях null в полях", мне кажется стабильным источником для багов.

Полностью с вами согласен! Хорошо что существуют UnitTest-Ы

Здравствуйте, SanyaVB, Вы писали:

[Skip]

Это называется проекция

db.Database.SqlQuery<TableClass>("GetFULLFirstRow").Select(t => new TableClass{ C1 = t.C1 }).FirstOrDefault();

И да, если вам не надо чендж трекера, то я бы лучше посмотрел на Linq провайдеры которые получше оптимизируют запросы и побыстрее работают.
Например linq2db