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

Например, в базе User(Id, Login, AddressId, ContactInfoId)
На клиенте — BEUser { Id, Login, Address, ContactInfo } — где Address и ContactInfo — это вложенные классы

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

return new BEUser{
Id = reader.GetInt32(reader.GetOrdinal("Id")),
ContactInfo  = new ContactInfo (){ Id = reader.GetInt32(reader.GetOrdinal("ContactInfoId")) }
//.................

Причем, нужно учесть, формат сущности не должен зависеть от его представления в базе.

У меня была идея сделать это через отражение (рефлексию), но тогда нужно вводить атрибуты и это сделает сущность зависимой от схемы базы данных.
Есть еще идея сделать это через Extension методы. Таким образом каждая сущность будет сама отпределять, как прочитать себя из базы.


Entity Framework и ORM не предлагать.

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

T4?

Вместо ORM нанять юного падована

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

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

A>T4?
что это?

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

D>Entity Framework и ORM не предлагать.
Я так понимаю, в них обнаружен фатальный недостаток? С учетом того, что рано или поздно вас должны посетить мысли относительно выборки по какому-то условию, обновлению и удалению, есть нехорошее предчувствие, что все закончится изобретением своего ORM.

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

D>>Entity Framework и ORM не предлагать.
HL>Я так понимаю, в них обнаружен фатальный недостаток? С учетом того, что рано или поздно вас должны посетить мысли относительно выборки по какому-то условию, обновлению и удалению, есть нехорошее предчувствие, что все закончится изобретением своего ORM.

Не знаю, что не нравится автору, а 3 случая я лично могу назвать с ходу:

1) Очень простые задачи. Например, пара Select и никаких Update/Insert вообще. От указанного кода избавиться хочется, но ОРМ здесь слишком тяжелы.

2) Очень сложные задачи. Например, пакетные изменения нескольких таблиц в БД, причем некоторые ссылаются сами на себя. ОРМ просто выпадают в осадок от таких схем.

3) Очень идиотские задачи. База данных плохо сопряжима с ОРМ. Например, primary key нет в принципе, связи между таблицами есть по составным ключам.

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

N_P>Не знаю, что не нравится автору, а 3 случая я лично могу назвать с ходу:
Ясен пень, ORM — не панацея. Но в таких примерах лучше с конкретикой вида "вот такая схема данных — вот такая модель — вот такой ORM — вот такой говенный запрос — вот такие удручающие результаты".
Иначе это сильно пополняет ряды лисапедистов. Те же ORM — они разные бывают.

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

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

D>>Entity Framework и ORM не предлагать.
HL>Я так понимаю, в них обнаружен фатальный недостаток? С учетом того, что рано или поздно вас должны посетить мысли относительно выборки по какому-то условию, обновлению и удалению, есть нехорошее предчувствие, что все закончится изобретением своего ORM.
возможно

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

D>Entity Framework и ORM не предлагать.
Ты описал ту задачу, благодаря чему ORM наз-ся Object Relation Mapping. Но ORM предлагать не буду.

D>Есть еще идея сделать это через Extension методы. Таким образом каждая сущность будет сама отпределять, как прочитать себя из базы.
Сущность не особо понимает какие extension к ней подключены.

GZ>Ты описал ту задачу, благодаря чему ORM наз-ся Object Relation Mapping.

Object-relational

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

D>Entity Framework и ORM не предлагать.

Не хотите писать код руками — используйте кодогенератор (T4 или CodeSmith). Но если вы не работали с ними раньше, то это решение возможно будет гораздо сложнее вашего проекта.

Поэтому стоит попробовать обойтись малой кровью и посмотреть на Linq2Sql + SqlMetal раз уж EF вас не устраивает.

Кстати вопрос к сообществу, если в конторе требуют CRUD 100% на хранимках, удачным ли выбором будет Linq2Sql + SqlMetal?

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

D>Можно ли как-нибудь автоматизировать процесс получения данных из DataReader, чтобы не писать каждый раз
D>Причем, нужно учесть, формат сущности не должен зависеть от его представления в базе.

В данном случае "автоматизация" может быть только наниманием индусов, которые будут мэпить поля. Комп на интуиции не работает, он должен однозначно сопоставлять инфу — либо все поля класса должны строго именоваться по колонкам БД, либо атрибуты. Ну или NOSQL!

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

D>Можно ли как-нибудь автоматизировать процесс получения данных из DataReader, чтобы не писать каждый раз

BLToolkit

Здравствуйте, Аноним, Вы писали:

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

А>Кстати вопрос к сообществу, если в конторе требуют CRUD 100% на хранимках, удачным ли выбором будет Linq2Sql + SqlMetal?

Да. У нас именно такая ситуация и такой выбор полностью себя оправдывает.
Рекомендую.

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

O>BLToolkit

Интересная штука? Вы лично его давно используете? Насколько оно стабильное?

Здравствуйте, Аноним, Вы писали:

Oyster> http://bltoolkit.net/

А>Интересная штука?

Даже круче WoW.

А> Вы лично его давно используете?

Мы его юзаем в продакшене 3 года. Нареканий практически никаких. Удобен настолько, что давно забыл про "стандартный" геморой от MS.

А> Насколько оно стабильное?

На стресс мы его не тестили, а по глюкам всё достаточно хорошо вылизано — если случается проблема, то как правило это несоответствие класса и таблицы. Я бы смело рекомендовал его использовать — безумно экономит время на надоедливые INS/UPD/DEL, возвращает удобные коллекции (списки и хэши), и это только тот примитив, который юзаем мы — там есть ещё более высокий уровень.
Вобщем, я бы посоветовал потратить на него время — он намного более простой и потому практичный, чем монстры типа хренобернейта.