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

IT>Здравствуйте, gloomy rocker, Вы писали:

GR>>>>У меня такое впечатление, что если переусердствовать с развитием этой библиотеки в облсти работы с BizEntity, то получим что-то типа System.Data.ObjectSpaces.

IT>Осталось только добавить описание в XML и поддержку абстрактных классов. И то и другое уже почти готово
О!!! Вот это круто. Может еще сделать чтобы можно было генерить схему БД, схему BizEntity и схему мапинга.
Потом все это компилится в сборку. А потом делаем производные классы и начиняем их бизнес логикой.
Методы и свойства, реализующие логику описываются в схеме и в сборке присутствуют как абстрактные.

а так же добавить что-то типа BizRelation и BizConstraint. Вот это будет улет

M>>>Не, ObjectSpaces — это немного другая... конструкция. Лучше всего TK об этом расскажет.
GR>>Да я и сам почитать могу. Только времени пока нет. Просто показалось что прогресс движется в сторону изобретения очередного велосипеда. Вот и возник такой вопрос.

IT>Только пока мы ждём и изобретаем будущий велосипед, MS в своих проектах как раз пользуется Rsdn.Framework.Data
Не удивлюсь, если это действительно так. Посмотрел на их "Data Access Application Block" и обнаружил много похожестей , но Rsdn.Framework.Data круче.

IT>Только пока мы ждём и изобретаем будущий велосипед, MS в своих проектах как раз пользуется Rsdn.Framework.Data

Да ладно, заливаешь

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

W> У меня же идет активная работа с датасетами в обе стороны, а никаких функций там не предусмотрено для Update()


Да, этого действительно очччень не хватает, в остальном же библиотека замечательная...

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

M>Да ладно, заливаешь

Ну не весь MS конечно , но один team of Microsoft Consulting Services я на это дело подсадил... ну и IBM за одно

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

GR>а так же добавить что-то типа BizRelation и BizConstraint. Вот это будет улет

Это должен быть отдельный продукт.

GR>Не удивлюсь, если это действительно так. Посмотрел на их "Data Access Application Block" и обнаружил много похожестей , но Rsdn.Framework.Data круче.

Ну я на DAAB как бы тоже поначалу поглядывал

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

IT>Здравствуйте, gloomy rocker, Вы писали:

GR>>а так же добавить что-то типа BizRelation и BizConstraint. Вот это будет улет

IT>Это должен быть отдельный продукт.
А было бы круто
Может обсудим в свободное от безделья время? Только сначала все же надо на ObjectSpaces посмотреть...

GR>>Не удивлюсь, если это действительно так. Посмотрел на их "Data Access Application Block" и обнаружил много похожестей , но Rsdn.Framework.Data круче.

IT>Ну я на DAAB как бы тоже поначалу поглядывал
Да я так и понял.

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

IT>Больше заточено на бизнес-объекты. Но дописать что-то ещё проблем нет, нужны только идеи как это сделать.

Вообще-то если честно, то я уже там для себя поломал частично код, сделал 4 commands на объект, в нужные ф-и в качестве параметра вставил енум, определяющий какой тип команды использовать (general, insert, delete, update), ну и собсна дописал ф-и для UpdateDataset. Только вот получилось в конце-концов что-то страшное вот исходник ф-и в DbManager (потом дальше пример использования):

/// <summary>
/// Updates database from the given dataset using provided UPDATE, INSERT and
/// DELETE SQL statements with provided parameters.
/// </summary>
/// <param name="dataSet">The DataSet object used to update database.</param>
/// <param name="tableName">The name of the populating table.</param>
/// <param name="updateCommandType">The <see cref="System.Data.CommandType">CommandType</see> (stored procedure, text, etc.) for update operation.</param>
/// <param name="insertCommandType">The <see cref="System.Data.CommandType">CommandType</see> (stored procedure, text, etc.) for insert operation.</param>
/// <param name="deleteCommandType">The <see cref="System.Data.CommandType">CommandType</see> (stored procedure, text, etc.) for delete operation.</param>
/// <param name="updateCommandText">The command text to execute in case of update operation.</param>
/// <param name="insertCommandText">The command text to execute in case of insert operation.</param>
/// <param name="deleteCommandText">The command text to execute in case of delete operation.</param>
/// <param name="updateCommandParameters">An array of paramters used to executes the update command.</param>
/// <param name="insertCommandParameters">An array of paramters used to executes the insert command.</param>
/// <param name="deleteCommandParameters">An array of paramters used to executes the delete command.</param>
/// <returns>The <see cref="DataSet"/>.</returns>
public DataSet UpdateDataSet(
    DataSet     dataSet,
    string      tableName,
    CommandType updateCommandType,
    CommandType insertCommandType,
    CommandType deleteCommandType,
    string      updateCommandText,
    string      insertCommandText,
    string      deleteCommandText,
    IDbDataParameter[] updateCommandParameters,
    IDbDataParameter[] insertCommandParameters,
    IDbDataParameter[] deleteCommandParameters)
{
    PrepareUpdateCommands(updateCommandType,
        insertCommandType, deleteCommandType,
        updateCommandText, insertCommandText,
        deleteCommandText,
        updateCommandParameters, insertCommandParameters,
        deleteCommandParameters);

    return UpdateDataSetInternal(dataSet, tableName);
}

Ну и пример (GetProviderString() достает SQL query):

using (DbManager db = CreateDataDbManager())
{
db.UpdateDataSet(
    dataSet, "Employees", CommandType.Text, CommandType.Text,
    CommandType.Text, GetProviderString("UpdateEmployee"),
    GetProviderString("InsertEmployee"),
    GetProviderString("DeleteEmployee"),
    new IDbDataParameter[]
    {
        db.Parameter("Title_ID", DbType.Int32, "Title_ID"),
        db.Parameter("FirstName", DbType.String, 50, "FirstName"),
        db.Parameter("LastName", DbType.String, 50, "LastName"),
        db.Parameter("Comments", DbType.String, 100, "Comments"),
        db.Parameter("ID", DbType.Int32, "ID")
    },
    new IDbDataParameter[]
    {
        db.Parameter("Title_ID", DbType.Int32, "Title_ID"),
        db.Parameter("FirstName", DbType.String, 50, "FirstName"),
        db.Parameter("LastName", DbType.String, 50, "LastName"),
        db.Parameter("Comments", DbType.String, 100, "Comments")
    },
    new IDbDataParameter[]
    {
        db.Parameter("ID", DbType.Int32, "ID")
    }
    );
}

Как-то очень длинно получилось, теперь вот думаю как это упростить. Как вариант может быть занести CommandType, CommandText и Parameters в отдельную структуру, чтобы все почище получилось и дефолты чтобы хоть какие чтобы проставлять можно было без несчетного количества перегруженных ф-й...

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

IT>>Это должен быть отдельный продукт.
GR>А было бы круто
GR>Может обсудим в свободное от безделья время? Только сначала все же надо на ObjectSpaces посмотреть...

Давай.

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

IT>Здравствуйте, gloomy rocker, Вы писали:

IT>>>Это должен быть отдельный продукт.
GR>>А было бы круто
GR>>Может обсудим в свободное от безделья время? Только сначала все же надо на ObjectSpaces посмотреть...

IT>Давай.
Вот только мне не дает покоя мысль, что в итоге получится Rsdn.Framework.Data.DataSet, Rsdn.Framework.Data.DataTable и т.д.

M>>Да ладно, заливаешь

IT>Ну не весь MS конечно , но один team of Microsoft Consulting Services я на это дело подсадил... ну и IBM за одно

Ну ты крут.

ИТ> пространства имён Rsdn.Framework.Data, представляющего собой высокоуровневую обёртку над ADO.NET.

А вот интерестно, нет ли в планах сделать ещё небольшой типа SQL-процессор, как в DataTable.Select к примеру, но на бизнес-объектах?

То есть, например:

public object[] Select(ICollection tableList, string filter, string sort)

Реализовать бы такое грамотно, с использованием Emit. Тогда действительно на ADO.NET можно понемногу забивать.

[]

Первым делом хотелось бы поблагодарить за замечательную библиотеку. А вторым делом хотелось бы рассказать про глюк с пулингом, причину которого мне установить не удалось — при использовании библиотеки в компоненте бизнес-логики ежели DBManager не Dispose-ить то из system.data.dll иногда вылетает InvalidOperationException и говорит "A connection pooling error has occured"
Никто с этим не сталкивался ? А то не хочется жить без пулинга

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

GR>Вот только мне не дает покоя мысль, что в итоге получится Rsdn.Framework.Data.DataSet, Rsdn.Framework.Data.DataTable и т.д.

Примерно так и будет, только называться это будет Rsdn.Framework.Data.BizEntity и Rsdn.Framework.Data.BizEntityList

[]

забыл добавить — exception вылазит при попытке закрыть _connection (DBManager.cs, 613)

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

M>Реализовать бы такое грамотно, с использованием Emit. Тогда действительно на ADO.NET можно понемногу забивать.

И генерировать на лету SQL? Тут тебя сразу запинают защитники "правильного" дизайна. И я буду между прочим в их числе

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

EM> Никто с этим не сталкивался ? А то не хочется жить без пулинга

Пулинг реализован внутри SqlConnection. Для того чтобы он работал корректно нужно диспозить соединение, в данном случае DbManager.

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

IT>Больше заточено на бизнес-объекты. Но дописать что-то ещё проблем нет, нужны только идеи как это сделать.

Кстати, если уж на то пошло, то еще пара замеченных проблем:
1. Ну это даже не проблема, а так, неудобство. Не хватает перегруженных ф-й Parameter() чтобы создать конкретный параметр с типом, размером (или без него) и сразу дать ему значение. Т.е. при использовании датасета все нормально, там можно указать sourceColumn, а вот если просто параметр со стороны... если конкретно — вот сигнатура которой не хватает:

public IDbDataParameter Parameter(string parameterName, DbType dbType, object value);
public IDbDataParameter Parameter(string parameterName, DbType dbType, int size, object value);

2. Это больше риторическая проблема. Заключается в том, что для разных провайдеров параметры указываются по-разному. Кому-то надо просто имя, кому-то вопросик, кому-то двоеточие обязательно перед именем параметра (у меня такой для MySql). А так как насколько я понял, библиотека ориентирована на использование с разными провайдерами, хотелось бы чтобы один и тот же запрос проходил одинаково для разных провайдеров. Пока что я это решил тем, что в самом запросе определенным образом помечаю параметр и перед использованием строки запроса заменяю параметр нужной строкой. В интерфейсе для провайдера для этого добавил ф-ю

string AdjustSqlParameter(string parameter);

Она возвращает такое представление параметра, которое нужно этому провайдеру.
Как насчет что-нибудь похожее реализовать у себя?

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

IT>Здравствуйте, gloomy rocker, Вы писали:

GR>>Вот только мне не дает покоя мысль, что в итоге получится Rsdn.Framework.Data.DataSet, Rsdn.Framework.Data.DataTable и т.д.

IT>Примерно так и будет, только называться это будет Rsdn.Framework.Data.BizEntity и Rsdn.Framework.Data.BizEntityList
Вот, вот! Велосипед форева. Хотя если эту библиотечку снабдить средствами кодогенерации, то может получиться оччень полезная вещь.
Мне например в типизирванном DataSet-е не хватает возможности добавить в какой-нить MyObjectRow собственный метод, реализующий бизнес-логику. Сейчас приходится решать это путем агрегации(наследоваться — себе дороже выйдет). Вот если бы решить эту проблему путем добавления абстрактных методов во время дизайна, а потом реализовать их. Но мне кажется, что в Whidby это(или что-то подобное) уже сделано. То есть если уж делать велосипед, то он должен быть легче DataSet-а, иначе смысла особого нет. А если реализовать все, что использую в DataSet-e, то получится еще один монстр.

В общем надо определиться с областью применения.

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

W>1. Ну это даже не проблема, а так, неудобство.

Сделаем.

W>2. Это больше риторическая проблема.

В юнит тестах я делаю примерно так же.

W>Как насчет что-нибудь похожее реализовать у себя?

Как это сделать, чтобы было не коряво

M>>Реализовать бы такое грамотно, с использованием Emit. Тогда действительно на ADO.NET можно понемногу забивать.

IT>И генерировать на лету SQL? Тут тебя сразу запинают защитники "правильного" дизайна. И я буду между прочим в их числе

А разве System.DataTable.Select генерирует на лету SQL?