.net: Предпочитаете ли вы заполнять таблицу данных при извлечении данных из базы данных или заполнять общий список вашего собственного объекта? - PullRequest
2 голосов
/ 31 января 2011

какой senario вы предпочитаете, когда извлекаете данные из базы данных?

1 - Заполнение таблицы данных и затем привязка к ней таблицы данных?

ИЛИ

2- заполнить список родовых объектов вашего собственного пользовательского объекта и затем привязать к нему сетку данных?

Спасибо

Ответы [ 2 ]

2 голосов
/ 31 января 2011

2 - список объектов: -)

причины (или, как отмечает Марк, «заслуги»):

  • меньший вес
  • возможность продлениясписок через пользовательский класс
  • возможность использования фильтров / linq для объектов таким образом, чтобы они лучше подходили для бизнес-объектов
  • DataTables являются специфическими для Microsoft.Если вам нужно передать их в сторонний, то есть веб-сервис Java, вам нужно будет создать отдельный бизнес-объект для передачи ему.
  • проверить текущие реализации OR / m - там не так много таблиц данных..
  • если это веб-проект, то сохранение соединения открытым во время чтения результатов в устройстве чтения данных - это что-то вроде «нет-нет»
  • DataTables почти умоляет разработчика разместить бизнес-логикуна уровне пользовательского интерфейса.Наличие области бизнес-правил в бизнес-объекте заставляет кодировщика размещать бизнес-правила в нужном месте.
  • модульное тестирование ваших результатов - гораздо проще в пользовательском классе, определенном через интерфейс
  • строгая типизация свойств (а не строковых индексов для данных полей)

также, использование DataTables напрямую означает привязку себя к базовому источнику данных и его структуре.С точки зрения ремонтопригодности это не очень хорошая идея.Если все, что вам нужно, это список некоторых объектов, это все, что вы должны ему дать (т.е. список).

[править] - это старая статья, но стоит добавитьк «дебатам»:

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

http://www.kellermansoftware.com/t-articlebusinessobjects.aspx

1 голос
/ 31 января 2011

Я бы не советовал работать с БД напрямую.Есть хорошие ORM: LINQ to SQL, Entity Framework и NHibernate.Кому нужны старые болезненные данные?

...