Путаница относительно правильного использования данных и наборов данных

Question

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

В принципе, я хочу, чтобы получить данные из базы данных с помощью хранимых процедур. Каждая из хранимых процедур извлекает данные из разных таблиц и может выполнять некоторые объединения. Эти данные затем отображаются в форме окна. Пользователь будет использовать эти данные, а затем либо добавить новую запись, либо обновить существующую в базе данных.

Один из методов, с которым я знаком, - это сделать отдельные вызовы базы данных, сохранить результаты в формате данных, а затем работать с этим объектом, чтобы отобразить его на экране. Это делается с помощью ADO.net. Это работает. Кроме того, использование набора данных для возврата всех этих данных из одного вызова базы данных (одна хранимая процедура) также работает. Но, по-видимому, это не идеальный или самый эффективный способ сделать что-то? Я не слишком хорошо знаком с LINQ, но это похоже на другой метод извлечения данных.

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

Мне кажется, что я уже разбираюсь в этом, и я уверен, что мне удалось смутить себя, когда дело доходит до всего этого. Я бы очень благодарен за комментарии и мысли по этому вопросу.

Answer 1

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

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

Answer 2

Один раз, когда DataTable (и т. Д.), Конечно, является полезен при написании специального инструмента, не предназначенного для схемы (где запрос и, следовательно, scheman известен только во время выполнения) - специальный инструмент отчетности, возможно , или что-то вроде SSMS.

DataTable также удобен для подачи SqlBulkCopy.

Многие люди утверждают, что для всего остального предпочтительны обычные классы C#. Конечно, очень редко я вижу DataTable в производственном коде в наши дни. Однако он может работать.

Лично мне нравится POCO + «dapper», который отнимает всю связанную работу (в том числе для SPROC), но прекрасно работает с типизированными классами моделей, без накладных расходов на все ORM.