Список <> лучше, чем DataSet для уровня пользовательского интерфейса в ASP.Net?

Question

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

Поэтому я задаюсь вопросом: лучше ли читать мои данные по DataReader и использовать их для заполнения List<BLClasses> или для заполнения DataSet и отправки DataSet на уровень пользовательского интерфейса ??.

Меня интересует хорошая производительность и масштабируемость.

Answer 1

Ваш уровень пользовательского интерфейса должен быть далек от вашей стратегии доступа к данным - он не должен иметь дело с необработанными данными. Таким образом, ваш пользовательский интерфейс должен взаимодействовать исключительно с объектами вашего домена (напрямую или через уровень обслуживания).

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

Это влияет на удобочитаемость, тестируемость и удобство сопровождения кода, которые всегда должны быть долгосрочными и краткосрочными целями любого проекта.

Я думаю, в идеале вы хотели бы увидеть что-то вроде этого:

 UI
 /|\
  |
SERVICE (? depending on the design)
 /|\
  |
DOMAIN
 /|\
  |
 DCO
 /|\
  |
 DAL

EDIT:

С другой стороны, если вы создаете очень прямолинейное приложение WebForms, вы можете отказаться от некоторых из этих сложностей и просто использовать конструкторы, предоставляемые Visual Studio. Однако я обнаружил, что приложения часто эволюционируют за пределы возможностей интерфейса перетаскивания, и в конечном итоге вам приходится проводить рефакторинг в более отдельный дизайн.

Вам всегда нужно знать, что вы стоите, чтобы получить / потерять, выбирая архитектурную стратегию. Если вы можете жить (на грани) без тестирования, снижения читабельности и более тесной связи пользовательского интерфейса с данными ****, то вы содрогнетесь ****, тогда, возможно, более простой подход для вас.

Некоторые ссылки для дальнейшего чтения

• ТВЕРДЫЕ принципы ООД
• PoEE Фаулера
• MSDN: шаблоны и практики

Answer 2

Я не знаю о производительности, но с точки зрения обслуживания и читабельности использование списка <> намного лучше.

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

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

Если производительность является проблемой, тогда посмотрите на другие общие коллекции, такие вещи, как словарь, имеют очень и очень хорошие свойства поиска ключей (по-видимому, почти n (1)), которые могут оказать огромное влияние на правильные места.

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

Answer 3

Проверка Сравнение производительности: методы доступа к данным . Он довольно старый, но содержит полезную информацию о производительности между DataSet, DataRader и XmlReader.

Answer 4

Я бы сказал, что было бы лучше использовать ваши пользовательские объекты вместо набора данных. Лучше всего, чтобы уровни пользовательского интерфейса и бизнеса были слепыми к тому, как вы реализуете свой доступ к данным. Любой способ, которым вы фактически общаетесь с вашим источником данных (db, xml, ect.), Должен содержаться на вашем уровне доступа к данным, а ваш бизнес-уровень должен просто ожидать ваших пользовательских объектов.

Answer 5

Использование List<T>, IList<T> или, что еще лучше, IQueryable<T> дает вам преимущество скрывать детали реализации за границей интерфейса. Это освобождает вас от необходимости менять порядок получения этого позднее.

Answer 6

Если вы беспокоитесь о производительности, взгляните на код для строго типизированного набора данных, и вы можете сами решить;)

Answer 7

Я бы предложил List <>, если вы просто читаете из БД и представляете в пользовательском интерфейсе. DataSet является довольно сложным и тяжелым классом, поэтому я хотел бы использовать его, только если вам нужны его специальные функции, такие как отложенные обновления, связи с данными и т. Д.

Answer 8

List<T> является типобезопасным - вы всегда знаете, что получаете, и вам никогда (редко) не приходится беспокоиться о касте. У вас нет такой роскоши с DataSet.

List<T> также имеет все встроенные вспомогательные методы Linq, если вы используете 3.0

.