System.ComponentModel.Component в Visual Studio 2008

Я поддерживаю приложение .Net 2.0 с помощью Visual Studio 2008. Когда приложение было построено, оно изначально было в Visual Studio 2003 и использовало класс System.ComponentModel.Component для доступа к данным. Вы можете перетаскивать команды, соединения и т. д. на поверхность конструктора компонента.

В версии 2008 классы доступа к данным не «привязываются» к компоненту. То есть код команды не генерируется в классе.

  1. когда это изменилось? 2005?
  2. есть ли замена этому поведению, возможно, с использованием версии db pro?

Спасибо.


person Mark A Johnson    schedule 13.05.2009    source источник


Ответы (1)


«Замена» осуществляется либо с использованием типизированных наборов данных (используйте «Добавить-> Новый элемент» и выберите «Набор данных», затем перетащите таблицы, представления или хранимые процедуры на поверхность конструктора). Или Entity Framework/LINQ to Entities.

И да, это изменилось в VS2005.


Небольшое исследование заставило меня задуматься, потому что «это работает для меня».

  1. Откройте простой проект библиотеки классов
  2. Щелкните правой кнопкой мыши и выберите «Добавить -> Компонент». Компонент создан, и отображается знакомая область разработки компонента.
  3. Просмотрите набор инструментов. Обратите внимание, что SqlCommand и т. Д. На нем нет. Щелкните правой кнопкой мыши панель инструментов и выберите «Выбрать элементы».
  4. Введите «System.Data» в поле фильтра. Это поможет вам найти всех ваших старых друзей, "SqlConnection", "SqlCommand", "SqlDataAdapter" и даже "DataSet" и "DataView". Выберите их все и нажмите «ОК».
  5. Перетащите SqlConnection на поверхность конструктора. Настройте его как обычно.
  6. Перетащите SqlCommand на поверхность конструктора, настройте как обычно. Я даже установил свойство Connection, чтобы оно указывало на мой первый SqlConnection.
  7. Перетащите «SqlDataAdapter» на поверхность конструктора. Появится обычное диалоговое окно «Настройка адаптера данных». Настройте адаптер, выберите «Создать набор данных» и т. д.
  8. Сохраните компонент и закройте его.
  9. Откройте компонент снова. Все эти части до сих пор присутствуют.

Что вы пробовали, что не сработало?

person John Saunders    schedule 13.05.2009
comment
Мы действительно используем типизированные наборы данных. Я имею в виду не объект передачи данных (DataSet), а доступ к данным (класс компонентов). Раньше можно было перетаскивать адаптеры, подключения, команды и т. д. из обозревателя серверов на поверхность класса компонентов. Теперь вы не можете. Я ищу замену этому, а не объекту передачи данных. - person Mark A Johnson; 13.05.2009
comment
Я, действительно, имел в виду типизированные DataSets. Новый конструктор DataSet создаст строго типизированный класс TableAdapter, который делает то же, что и класс DataAdapter, но строго типизированным образом. Попробуйте то, что я предложил. Новый набор данных, перетащите таблицы и перетащите хранимые процедуры. Посмотрите на сгенерированный код. Посмотрите, что там. - person John Saunders; 13.05.2009
comment
Ах, мое замешательство возникло из-за того, что вы использовали типизированные наборы данных, которые можно использовать и обычно используют без адаптеров таблиц. Знание того, что вы действительно имели в виду TableAdapters, проясняет это для меня, хотя на самом деле это еще не ответ на мой вопрос. Меня больше интересует, как изменилось использование Component Class для доступа к данным, чем перепроектирование моего решения. Любая идея, как или когда класс компонента изменился по отношению к объектам базы данных? - person Mark A Johnson; 13.05.2009
comment
О, ваше исследование очень полезно. Я попытаюсь воссоздать это. Что у меня не сработало, так это перетаскивание элементов (например, сохраненных процессов) непосредственно из обозревателя серверов. Я попробую ручное создание, перетаскивая элементы управления из панели инструментов. Спасибо! - person Mark A Johnson; 13.05.2009
comment
Серьезно, DataSet Designer уже не тот, что раньше. Попробуйте перетащить на только что созданный DataSet. Перетащите таблицу и перетащите SP, который возвращает набор результатов, и тот, который не возвращает. Предпочтительно использовать SP с параметрами. Затем посмотрите на сгенерированный код и посмотрите, что вы думаете. Это уже не так плохо, как раньше, и семантика не так уж и далека. Это похоже на код оболочки, который вам, вероятно, уже нужно обернуть DataAdapter.Fill. - person John Saunders; 13.05.2009
comment
Дело не в том, что код может быть уродливым. Дело в том, что у нас есть очень большое приложение, которое мы поддерживаем. Хотя код может быть лучше старого, усилия по изменению архитектуры этой части приложения (десятки классов доступа к данным) могут не стоить обновления. - person Mark A Johnson; 13.05.2009
comment
Ничего страшного, если это слишком дорого. Мне все равно не нравятся типизированные наборы данных. Когда вы приступите к обновлению своего DAL, я бы использовал Entity Framework и LINQ to Entities. Я упомянул типизированные наборы данных, потому что они очень близки к тому, что у вас уже есть, а не потому, что это такая замечательная технология. - person John Saunders; 14.05.2009