Сколько должен представлять один DataSet?

Question

Сколько должен представлять один DataSet? Используя пример системы заказа: при показе вашего заказа я также показываю список товаров, похожих на один из ваших, а также список наших самых популярных товаров. В то время как ваши товары запутаны в сети отношений, в которых участвуют вы и ваши прошлые заказы, предпочтительные поставщики и различные другие виды информации, относящиеся к вам как к клиенту, другие товары не имеют таких же отношений. Набор запросов, которые я использую для навигации по набору материалов, представляющих вас, отличается от запросов, которые я использую для одного из этих других списков элементов.

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

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

Answer 1

Набор данных сильно переоценен и чрезмерно используется. Используйте строго типизированные коллекции (спасибо, дженерики и автоматические свойства!). Как пирог, теперь вы даже можете выполнять классные запросы по вашим пользовательским объектам с помощью LINQ.

Хорошая статья в Esposito о наборах данных и пользовательских объектах:

http://msdn.microsoft.com/en-us/magazine/cc163751.aspx

Автоматические свойства:

http://weblogs.asp.net/dwahlin/archive/2007/12/04/c-3-0-features-automatic-properties.aspx

LINQ с вашими объектами:

http://blogs.msdn.com/wriju/archive/2006/09/16/linq-custom-object-query.aspx

Answer 2

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

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

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