Библиотека доступа к данным возвращает набор данных или объект

Я также использую dataReader, но имейте в виду, что если вы это сделаете, вы должны быть осторожны, чтобы закрыть его (и соединение, которое он использует) как можно быстрее после того, как вы закончите заполнение настраиваемого объекта (ов). обратите внимание на то, что при вызове OpenReader () убедитесь, что вы передаете необязательный параметр CommandBehavior, установленный в CommandBehavior.CloseConenction, или, даже если вы закроете средство чтения, базовое соединение не будет закрыто и передано в пул, пока оно не получит выбирается сборщиком мусора, что может легко привести к тому, что у вас закончатся доступные соединения, если вы вызываете несколько объектов чтения в цикле.

В какой-то момент это зависит от цели библиотеки, или, я бы сказал, функциональности библиотеки. Поскольку шумиха вокруг ООП, «общий консенсус» заключается в том, чтобы сначала получить / извлечь данные в DAL с помощью загрузчиков данных, поскольку они работают быстрее, а затем загрузить свои объекты и закрыть своих читателей, однако это не всегда так. Для простоты некоторые передают набор данных обратно, чтобы можно было ограничить просмотры сетки и включить разбиение по страницам / сортировку с минимальным кодом. Помните, что простое лучше.

Однако в приложении для создания отчетов я заметил сходство наборов данных, особенно если данные предоставляются веб-службами.

Стоимость сериализации будет зависеть от использования приложения, а также опыта. Неопытный разработчик может вернуть от 3000 до 50000 строк ненужных данных в наборе данных. Помните, что набор данных - это животное, но с большим количеством функций. Используйте с умом.

Большинство ORM выполняет сериализацию за кулисами (здесь я исправлюсь), поэтому было бы справедливо сказать, что это не будет стоить так дорого, но опять же, это зависит от приложения.

Лично я использую SqlDataAdapter с DataTables. DataTables имеют на СПОСОБ меньше накладных расходов, чем DataSets. Мои объекты сущности содержат только бизнес-правила, они не используются для передачи данных между уровнями.

Вы можете подумать о том, чтобы пропустить библиотеку доступа к данным; вместо этого сделайте так, чтобы ваши бизнес-объекты были автоматически там для вас, заполнены данными, когда они вам понадобятся. NHibernate.

Я должен согласиться с Джастисом, не обязательно с NHibernate (хотя это отличный вариант), я бы определенно посмотрел на использование какого-то ORM, такого как NHibernate, Subsonic, Linq-to-sql, llblgen или любой другой из ORM вокруг .

Как Джереми Миллер заявляет:

if you're writing ADO.Net code by hand, you're stealing from your employer or client.

и с этой целью я бы рекомендовал возвращать объекты, а не наборы данных или таблицы данных.

Кроме того, если вы возвращаете наборы данных, если вы строго не набираете каждый набор данных, вам придется написать много «подъемного» кода в вашей библиотеке, чтобы получить значения из наборов данных. С ORM и объектами вся тяжелая работа будет сделана за вас.

Наконец, с Linq в C# вы теперь получаете гораздо лучшую функциональность для работы с коллекциями (агрегаты, группировка, сортировка, фильтрация и т. д.), Которые могли дать наборам данных преимущество.