Добрый день,
Подскажите пожалуйста, оправданно ли следующее.

WinForms. Ввиду определенной специфики требований приложения (большего вы от меня не узнаете ) моделью данных является типизированный DataSet, который биндится к элементам управления. DataSet не 1:1 база данных, где надо расширен «временными» таблицами и/или полями. Сразу скажу, от дата сета очень тяжело отказаться, практически невозможно.
В принципе все нормально, но иногда при выборке дынных из базы данных при помощи адаптеров происходит очень интенсивное и многократное обращение к базе. Поясню. Допустим нужно получить записи некоторой таблицы по определенному критерию, и отобразить их. Каждая запись имеет множетсво внешних ключей и нужно в датасет подгрузить записи, соответствующие этим ключам. Загрузить данные из несколькох таблиц в одном запросе Адаптеры не позоволяют, приходится прогонять полученных результат и подгружать внешние таблицы по ключу, для каждого ключа отдельно. В общем – очень ресурсоемкие обращения к базе получаются. В EF конечно же все намного проще, метод Include загружает результат в одном запросе (Include выраждается в SQL-JOIN и потом мапится на Navigation-Properties).

Возникла идея смешать эти два подхода – EF – как AccessLayer и DTO, а моделью данных, что используется на клиенте DataSet.

Вообще, во многих местах программы, так где не требуется DataSet, я мог бы и хотел бы использовать EF.

Вопрос – стоит ли мешать две технологии EF и дата сет? Или проблему, описанную мной, можно как-то обойти.

Спасибо.

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

SL>Загрузить данные из несколькох таблиц в одном запросе Адаптеры не позоволяют,
Отлично позволяют. Просто возвращаете в запросе несколько результатов.
По умолчанию они мапятся в порядке следования таблиц в датасете, но можно задать явно любой другой маппинг.

SL>приходится прогонять полученных результат и подгружать внешние таблицы по ключу, для каждого ключа отдельно. В общем – очень ресурсоемкие обращения к базе получаются.
Конечно. Но так делать не надо.

SL>Возникла идея смешать эти два подхода – EF – как AccessLayer и DTO, а моделью данных, что используется на клиенте DataSet.
DTO в таком подходе, как мне кажется, не нужно (если это не через web service). Прямо из EF запроса в датасет и перекладывать.

SL>Вообще, во многих местах программы, так где не требуется DataSet, я мог бы и хотел бы использовать EF.
SL>Вопрос – стоит ли мешать две технологии EF и дата сет?
EF и DataSet — не противоречат друг другу. Не совсем корректно выбирать между EF и DataSet.
Можно выбирать между DataSet и POCO для модели данных и между EF и ADO.NET для доступа к ним.

SL>Или проблему, описанную мной, можно как-то обойти.
В вашем случае (как я его понял) не вижу смысла их смешивать. Пусть часть программы работает с DataSet + DataAdapter (По крайней мере, для чтения данныз, обновления — отдельный разговор), а часть — с EF + POCO.

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

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

SL>>Загрузить данные из несколькох таблиц в одном запросе Адаптеры не позоволяют,
V>Отлично позволяют. Просто возвращаете в запросе несколько результатов.
V>По умолчанию они мапятся в порядке следования таблиц в датасете, но можно задать явно любой другой маппинг.

Тогда, пожалуйста, научите как. Я данную проблему иследовал, не получается.
Я могу в одном SQL запросе использовать несколько Select-от для разных таблиц. Результат мапится на две и более таблиц. Но все Select-ы независимы друг от друга. Мне не это нужно, а аналог Include() из EF. А здесь уже совсем другая история. Запрос включает "зависимые" таблицы через оператор JOIN. Результат содержит ничего лишнего, только записи "главной" таблицы, и из JOIN дополнительных колонках данные "зависимых" таблиц. Затем уже результат мапится на Entity-Обьекты.

Выполнить сие с помощью DataSet и адаптеров никак не получается. Это является основной загвоздкой

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

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

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

SL>>>Загрузить данные из несколькох таблиц в одном запросе Адаптеры не позоволяют,
V>>Отлично позволяют. Просто возвращаете в запросе несколько результатов.
V>>По умолчанию они мапятся в порядке следования таблиц в датасете, но можно задать явно любой другой маппинг.

SL>Тогда, пожалуйста, научите как. Я данную проблему иследовал, не получается.
SL>Я могу в одном SQL запросе использовать несколько Select-от для разных таблиц. Результат мапится на две и более таблиц. Но все Select-ы независимы друг от друга. Мне не это нужно, а аналог Include() из EF. А здесь уже совсем другая история. Запрос включает "зависимые" таблицы через оператор JOIN. Результат содержит ничего лишнего, только записи "главной" таблицы, и из JOIN дополнительных колонках данные "зависимых" таблиц. Затем уже результат мапится на Entity-Обьекты.

SL>Выполнить сие с помощью DataSet и адаптеров никак не получается. Это является основной загвоздкой

А нельзя решить проблему используя BindingList и EF?

Q>А нельзя решить проблему используя BindingList и EF?

Нет. Мне кажется вы не поняли мою проблему, или я не понял вас

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

SL>>>Загрузить данные из несколькох таблиц в одном запросе Адаптеры не позоволяют,
V>>Отлично позволяют. Просто возвращаете в запросе несколько результатов.
V>>По умолчанию они мапятся в порядке следования таблиц в датасете, но можно задать явно любой другой маппинг.

SL>Тогда, пожалуйста, научите как. Я данную проблему иследовал, не получается.
SL>Я могу в одном SQL запросе использовать несколько Select-от для разных таблиц. Результат мапится на две и более таблиц. Но все Select-ы независимы друг от друга. Мне не это нужно, а аналог Include() из EF. А здесь уже совсем другая история. Запрос включает "зависимые" таблицы через оператор JOIN. Результат содержит ничего лишнего, только записи "главной" таблицы, и из JOIN дополнительных колонках данные "зависимых" таблиц. Затем уже результат мапится на Entity-Обьекты.

SL>Выполнить сие с помощью DataSet и адаптеров никак не получается. Это является основной загвоздкой
Сделайте это прямо в SQL. Примерно так:

SELECT Column1, Column2, ... , ColumnX
FROM ParentTable
WHERE {condition}

SELECT ChildTable.Column1, ChildTable.Column2, ... , ChildTable.ColumnY
FROM ChildTable
INNER JOIN ParentTable ON ParentTable.Key = ChildTable.ParentKey
WHERE {condition}

TypedDS result = new TypedDS ();
string[] tableNames = new string[] 
{
    result.ParentTable.TableName,
    result.ChildTable.TableName
};
...
using (SqlDataAdapter adapter = new SqlDataAdapter(selectCommand))
{
    for (int i = 0; i < tableOrder.Length; i++)
    {
        string tableName = (i == 0)
           ? "Table"
           : "Table" + i.ToString(NumberFormatInfo.InvariantInfo);
        adapter.TableMappings.Add(tableName, tableOrder[i]);
    }
    dapter.Fill(result)
}

SL>>Выполнить сие с помощью DataSet и адаптеров никак не получается. Это является основной загвоздкой
V>Сделайте это прямо в SQL. Примерно так:
V>

V>SELECT Column1, Column2, ... , ColumnX
V>FROM ParentTable
V>WHERE {condition}

V>SELECT ChildTable.Column1, ChildTable.Column2, ... , ChildTable.ColumnY
V>FROM ChildTable
V>INNER JOIN ParentTable ON ParentTable.Key = ChildTable.ParentKey
V>WHERE {condition}
V>

V>

V>TypedDS result = new TypedDS ();
V>string[] tableNames = new string[] 
V>{
V>    result.ParentTable.TableName,
V>    result.ChildTable.TableName
V>};
V>...
V>using (SqlDataAdapter adapter = new SqlDataAdapter(selectCommand))
V>{
V>    for (int i = 0; i < tableOrder.Length; i++)
V>    {
V>        string tableName = (i == 0)
V>           ? "Table"
V>           : "Table" + i.ToString(NumberFormatInfo.InvariantInfo);
V>        adapter.TableMappings.Add(tableName, tableOrder[i]);
V>    }
V>    dapter.Fill(result)
V>}
V>

Похоже на то, я завтра обязательно испробую это. Спасибо!

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

SL>Добрый день,
SL>Подскажите пожалуйста, оправданно ли следующее.

SL>WinForms. Ввиду определенной специфики требований приложения (большего вы от меня не узнаете ) моделью данных является типизированный DataSet, который биндится к элементам управления. DataSet не 1:1 база данных, где надо расширен «временными» таблицами и/или полями. Сразу скажу, от дата сета очень тяжело отказаться, практически невозможно.

Если сразу невозможно, я бы постепенно мигрировал с датасета на EF. Контекст тоже можно "расширить" временными таблицами и полями.