Использование строго типизированного DataSet в проекте VB.Net

Question

Хорошо использовать строго типизированный набор данных.

В настоящее время я работаю над проектом, разработанным с использованием VB.Net в Visual Studio 2010.

Ранее они использовали запросы Sql непосредственно в SqlCommand System.Data.SqlClient, но затем после того, как я переместил все в строго типизированный DataSet и начал использовать TableAdapters везде где ...

Теперь я просто хочу спросить, что этот путь хорош для проекта ... Или я должен вернуться к старым, используя Just SqlCommands

Или есть ли способ сделать Sql DataBase хорошим способом, потому что это ERP и большая часть кода предназначена для доступа к данным.

Answer 1

Мы сейчас используем строго типизированные наборы данных.

После перехода к такому поведению стало очень плохо иметь SQL-запросы в коде вместо того, чтобы делать это с помощью адаптера таблицы. Но с наборами данных есть некоторые накладные расходы, так что я думаю, что способы стендов хороши для разных решений.

Действительно хорошо иметь интеллигентность для всех имен полей, и если вы меняете табличный адаптер так, чтобы он возвращал что-то другое, вы получаете ошибки времени разработки везде, где вам нужно изменить код, чтобы отразить изменение, вместо того, чтобы узнавать время выполнения, когда клиент запускает программу.

Есть так много выигрышных вещей со строго типизированными наборами данных, поэтому я никогда не вернусь.

Answer 2

Если вы когда-нибудь захотите переместить ваши данные по проводам на другие платформы (silverlight, веб-службы, службы wcf и т. Д.), То использование любого типа набора данных уведет вас в угол.

Способчто мы решили это, чтобы иметь классы, список свойств которых точно соответствует базе данных.Чтобы переместить данные в базу данных и из нее, мы используем отражение, чтобы либо сопоставить параметры хранимой процедуры, либо сгенерировать динамические операторы SQL в зависимости от обстоятельств и платформы.

Когда таблица базы данных изменяется, разработчик делаетИзменение также отвечает за обновление структуры классов и наоборот.

Чтобы уменьшить объем необходимого ручного кодирования, мы используем возможности CodeSmith для генерации кода для генерации классов из базы данных и создания основныхреализации наших стандартных хранимых процедур добавления / обновления, которые требуют перечисления полей.

В качестве дополнительного преимущества этот подход устраняет тесную связь между базой данных и структурой бизнес-объектов.Мы можем использовать один и тот же код доступа к данным и классы бизнес-объектов для баз данных SQL Server, Oracle, Sqlite и SqlServerCE.Этот код используется для создания приложений в приложениях Windows, PocketPC, Web, iPad и Android;все мобильные приложения используют локальные базы данных, специфичные для платформы, но с использованием общего кода доступа к данным.

Первоначальная настройка немного сложнее, но в долгосрочной перспективе это принесет значительные дивиденды.

Answer 3

Адаптеры таблиц .... создают много путаницы с большими базами данных, также обновление структуры таблиц также вызывает путаницу. Я бы порекомендовал использовать некоторые авто генераторы кода для операций CRUD. Для меня ваш старый шаблон выглядит лучше, чем переключение в целом на адаптеры таблиц и строго типизированные наборы данных.