Привет всем! Писание реальной финансовой программы на VS 2005 привело нас к мысли, что создатели дизайнера типизированного DataSet не имели дело с реальными задачами! Полная невозможность его работать с динамически формируемыми запросами ставит под вопрос за чем он нужен? Хотелось бы узнать мнение разработчиков, кто уже пишут реальны программы. Удалось его приручить или пришлось перейти на прямое кодирование, как это было в VS 2003? Итак, пожалуйста, проголосуйте — нужен или не нужен в реальной практике типизированный датасет?
Привет! В VS 2003 SqlCommand. Когда вы формируете текст с параметрами то вы пишите текст запроса, добавляете параметры указываете их типы. В типизированном DataSet можно добавить Query но только для Adaptera!
Привет! В VS 2003 SqlCommand. Когда вы формируете текст с параметрами то вы пишите текст запроса, добавляете параметры указываете их типы. В типизированном DataSet можно добавить Query но только для Adaptera!
Более того в описании сказано, что можно добавлять новые Query к TableAdapter, но The first query in a TableAdapter is the TableAdapter's main query! All queries listed below the main query are additional queries ! Поэтому динамически менять Update Insert не получится!
Реальная практика бывает разная. Задачи бывают разные. Самое неудачное решение — подстраиваться под механизмы, созданные кем-то для.. немножко других задач
Поэтому вам надо тщательно проанализировать, как вы в целом хотите решать задачу, а затем — подходят ли вам при этом типизированные датасеты в том виде, в каком их дает MS. Если не подходят — выкидывайте без сожаления.
Из личной практики — неплохо себя показали самодельные (своим генератором) типизированные DataTable'ы. Но! Это опять-таки, в приложении к конкретной задаче.
Re: Нужен в реальной практике типизированный датасет?
От:
Аноним
Дата:
28.09.05 01:49
Оценка:
Вам никто не запрещает работать по старинке. Нарисовать типмзированную схему а потом её заполнять или апдейитить с помощью DataAdapter.
Кстати TableAdapter именно так и делает. К томуже можно поступить еще курче. Написать свой DataAdpater. За особенностями реализации(я имею ввиду атрибуты, да и сами методы) стоит обратится в файл генерируемый типизированным дата сетом.
Последнее время, практика разработки в мелкомягких продуктах наводит на крамольную, близкую к шизофрении мысль: Микрософту НЕ НУЖНЫ умные, опытные программисты на платформе Windows. Всё, что надо юзеру, она напишет сама, а в это время... отдел по одебиливанию программистов сделает очередной финт ушами: вместо решения проблем придумают "новый и ещё более простой" способ передать записи из базы на клиента. Естественно, с новыми классами и методами. И пока мы как последние кретины бегаем по курсам, листаем книжки и набиваем шишки на их граблях (попутно отлаживая им код), они делают своё дело — расширяют спектр "продуктов", заполняя потенциальные ниши своим Г.
Я не знаю ни одной успешной технологии, придуманной мелкомягкими: Win32, DDE, OLE, ODBC, COM, SOAP(?), OLE DB, DirectX, теперь вот .NET...; Библиотек написано до черта, а как сидели мы на уровне 80-ых, так там и остались. Ни базы данных писать легче не стало, ни сетевые приложения, ни графику... какой-то застой, блин! Ненавижу буржуев.
PS
Чуть не забыл про основную тему Typed DataSet — из той же оперы "ещё легче, ещё быстрее" — пустая трата времени, не дающая никаких значимых преимуществ.
Привет всем! Похоже на то что отдельный ToolBox DataSource это всего лишь рекламный ход. Да для показа очень не плохо! Кинул на форму и вот тебе готово. В реальной работе мало применим.
Здравствуйте, Thornik, Вы писали: T>Я не знаю ни одной успешной технологии, придуманной мелкомягкими: Win32, DDE, OLE, ODBC, COM, SOAP(?), OLE DB, DirectX, теперь вот .NET...; Библиотек написано до черта, а как сидели мы на уровне 80-ых, так там и остались. Ни базы данных писать легче не стало, ни сетевые приложения, ни графику... какой-то застой, блин! Ненавижу буржуев.
Похоже, ты не писал в 80х ни базы данных, ни сетевые приложения, ни графику.
Я вот начал писать только в 91, и прекрасно помню, сколько секса было связано с простейшими вещами. И с базой данных, где рулил чудовищный Clipper а то и Ребус (никто не помнит такого клона dBase?). Сетевых приложений я тогда не писал — и слава богу, потому что до WinSock и повсеместного распространения TCP/IP на персоналках оставались годы. Графика была в ужасающем состоянии — просто вывести на экран надпись приличным шрифтом было невозможно. А как насчет печати графики на принтер? Я учил наизусть епсоновские коды управления.
Так что твои заявления полностью беспочвенны.
Впрочем, ты можешь их легко опровергнуть — напиши простейшие сетевые графические крестики-нолики. С хранением таблицы результатов в базе данных, ну, скажем, FoxPro. Платформа: MS-DOS 3.30. Язык: любой.
У меня, я думаю, на это уйдет часа три-четыре на VS 2005.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Нужен в реальной практике типизированный датасет?
Здравствуйте, mikl bob1, Вы писали:
MB>Привет всем! Писание реальной финансовой программы на VS 2005 привело нас к мысли, что создатели дизайнера типизированного DataSet не имели дело с реальными задачами! Полная невозможность его работать с динамически формируемыми запросами ставит под вопрос за чем он нужен? Хотелось бы узнать мнение разработчиков, кто уже пишут реальны программы. Удалось его приручить или пришлось перейти на прямое кодирование, как это было в VS 2003? Итак, пожалуйста, проголосуйте — нужен или не нужен в реальной практике типизированный датасет?
Участвовал в разработке системы (WinForms) где в основу был положе типизированый DataSet. Все работает нормально. Отчеты слделали на нетипизированых, или вооще без DataSet'ов.
Typed DataSet — из той же оперы "ещё легче, ещё быстрее" — пустая трата времени, не дающая никаких значимых преимуществ.
