сделал ADODB.Recordset + Forms - работает
Я новенький в этом форуме, так что если что не так, не пинайте больно. :)
Вопрос вот в чем: я сделал обвязку для ADODB.Recordset, которая с одной стороны имеет все плюсы этой технологии, с другой стороны, прекрасно дружит с .NET контролами (биндинги, добавление\удаление строк, поиск, фильтр, сортировка, курсор)
Насколько востребована такая технология?
Насколько я знаю, сейчас все фанатеют от бизнес-объектов, однако уверен, осталось еще много людей, которые не переползают на .NET именно из-за сложности перевода на ADO.NET.
Востребованность сомнительна.... Сдается мне, вы опаздали лет на 5 с такой библиотекой.
Перевода чего? ADO.NET существенно проще.
Может быть проще в сохранении данных на сервер?
Или проще в количестве кода, который надо написать для того чтобы он что-либо начал делать?
То что опоздал - согласен, но мне раньше и не надо было. 8)
Меня просто удивило, с чего вдруг все разом так полюбили ADO.NET
Не вижу ее преимуществ в клиент-серверных приложениях.
В WEB - да, а вот в обычных прикладных программах Киент-Сервер (бухгалтерия, торговля, и т.п.) незаметно, по крайней мере для меня.
Объем кода - да, вырос в разы. Только 90% кода - мусор. Всевозможные обвязки, обертки и т.п.
Все с точностью до наоборот. Я руки отрывал бы тому, кто использует датасеты под вебом. Они слишком тяжелые для этого. ADO.NET ничего общего с моделью многослойных приложений не имеет (подразумеваю разделение логики DataStore - Data transfer objects - Buissines Logic - Interface Logic). Говорите много кода, да только этот код в основном генерирует дизайнер набора данных. Вся остальная морока - попытки связывания логики приложения с достаточно "плоскими" строками датасета.
Проблема будет решаться если отказаться от датасетов в пользу некоторых ОРМ, микрософт вон LINQ предлагает.
У меня есть своя собственная надстройка над ADO.NET, работает на базе примитивных классов работы с БД (DbConnection, DbCommand), чем-то похожа на bltoolkit.
Исключительно на ADO.NET сделать нормальную архитектуру "модели предметной области" (апеллирую к domain driven development) не получится - это факт.
А про "любовь" - ADO.NET это единственная стандартная дырка в дотнете для работы с БД (да, да DbCommand - это адонетный класс!).
А что с DataSet, что с ОРМ возникает существенный вопрос: "нафига козе баян?"
Зачем мне писать кучу хранимок на сервере, кучу кода описывающего сущность обьекта на клиенте, кучу обвязок для загрузки\сохранения все в том же клиенте, если мне надо поправить значения просто в таблице?
Да, на этой таблице висят констрейнты, да хочется валидировать перед сохранением значение на клиенте, но это не задачи для ОРМ. Ну а по скорости работы я молчу. Если мне нужно отгрузить 2000 накладных в пакетном режиме (например, когда идет интенсивный обмен данными со складом) при варианте, когда на клиенте созданы объекты этих накладных отгрузка для программиста делается легко (бежишь по списку и вызываешь метод у объекта), да но для пользователя... Для пользователя это оборачивается ожиданием. Долгим ожиданием.
А когда у пользователя машина не суперновая (например, целерон с 256 мб памяти) вот тут начинаются вообще чудеса. 8)
Возможно, мои задачи и весьма прикладные, но честно говоря, мне нужны средства, которые сейчас решат (и быстро) существующую проблему. Можно конечно, собрать экскаватор и быстро вырыть им яму. Вот только беда - для каждой ямы придеться у экскаватора делать новый ковш. А есть лопата - пусть и с виду неказиста, зато работает и как ни странно быстрее (пока соберешь экскаватор, ковш новый прикрутишь, опять же экскаватору нужна солярка и место для разворота).
Удивляет отсутствие вообще каких-то простых и быстрых решений на эту тему. Уже три года плотно пишу на VB.NET (из приложений - работающий магазин для гиперов, сейчас пишем офисную часть), общаюсь с коллегами, но народ просто зомбирован новыми "супертехнологиями". Отметил для себя, что хотя уже и строчу весь день не поднимая головы, как машинистка, выхода - минимум... Каждая новая "супертехнология" должна сделать кодирование "еще быстрей и безопастней", только что толку. Там где я раньше писал одну строчку - пишу 50 строк. То, что раньше работало на PII сейчас еле ворочается на Core2DUO с 4 гб памяти....