Путаница с 3-слойным дизайном

Question

Я рассматривал примеры в Интернете из 3-х слоев, и я заметил, что большинство образцов возвращают либо наборы данных, либо таблицы данных. То, что меня смущает, - это то, что если вы предпочитаете возвращать общий список типов, чтобы вы могли использовать свойства или методы из того типа, на котором основан ваш список? В качестве примера, использующего свойство Name, которое конкретизирует различные поля определенным образом в зависимости от данных, если List связан с элементом управления в форме, тогда свойство Name может использоваться как поле данных. Если вы захотите выполнить то же самое при использовании набора данных или таблицы, вам придется возвращать данные из базы данных, чтобы добиться того же (я стараюсь не использовать наборы данных или datatables, поэтому я, вероятно, очень ошибаюсь в отношении этого утверждения . :))

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

Пример в приведенной ниже ссылке демонстрирует, по существу, использование наборов данных или таблиц, а затем добавление их к объекту, но я вынужден спросить, является ли это лучшей практикой?

http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET

Благодаря

Answer 1

Использование DataTable сек является специфическим dotnetism. Причина этого заключается в том, что они содержат метаданные о структуре данных, которые позволяют DataGrid (и другим таким компонентам) автоматически отображать данные без использования отражения или так. Я предполагаю, что это, среди прочего, наследие подхода MS Access к RAD, где цель заключалась в том, чтобы «деловые люди» могли создавать приложения, создавая пользовательский интерфейс непосредственно из схемы SQL, по существу делая противоположность многоуровневого дизайна. Это наследие, похоже, просочилось в hivemind.

Нет ничего плохого в использовании «простых» структур данных, если вы готовы отказаться от функций RAD, и в последнее время тенденция, похоже, заключалась в том, чтобы избавиться от этого компромисса. (Например, с помощью строго типизированных элементов управления веб-формами и функций привязки модели MVC.)

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

Answer 2

Что вы должны переносить свои данные, полностью зависит от ваших потребностей.

Если вы извлекаете данные из БД и привязываете их к datagrid, наборы данных могут дать вам идеальное решение. Если вам нужен другой метод, в котором данные отслеживают его собственный статус обновления, вы должны изучить Entity Framework. Если вы извлекаете данные и отправляете их через веб-службу для кросс-платформенной или кросс-доменной обработки, вам необходимо загрузить свои данные на некоторые другие сериализуемые классы.

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

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

Answer 3

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

Прежде чем сущность рамки, когда я написал уровень доступа к данным, я бы вернул общий список, который я создал из базы данных. Чтобы запустить обновление, удалить или вставить, я передал бы объект в качестве параметра методам, а затем использовал свойства объекта в качестве значений в инструкции sql. Я предпочел сделать это по причинам, упомянутым вами, но также и потому, что это позволило мне изменить определения объектов или схему db (или даже использовать разные db все вместе) независимо друг от друга.