Зачем создавать классы для представления данных в веб-приложениях? - PullRequest
Новая
       15

Зачем создавать классы для представления данных в веб-приложениях?

3 голосов
/ 23 мая 2011

В прошлом я обычно использовал классы для представления своих данных в приложениях, которые я проектирую и создаю. Но в веб-приложениях это, кажется, не нужно / не применимо, потому что данные хранятся в базе данных, и такие вещи, как DataSet, отлично работают для извлечения и сохранения данных.

В настоящее время я работаю с ASP.NET, и элементы управления с привязкой к данным (такие как GridView), похоже, любят привязываться к SqlDataSource, ObjectDataSource, DataView и т. Д. Итак, учитывая статический * Класс 1008 *, который вытаскивает DataSet из базы данных, мой код страницы, ориентированный на данные, часто выглядит примерно так: 

DataSet employeeData = MyDB.GetData();
DataView dvEmpData = new DataView(employeeData);
grdData.DataSource = dvEmpData;
grdData.DataBind();

Таким образом, у меня, как правило, нет классов данных, соответствующих схеме моей базы данных. Но новые разработки, такие как POCO и EF Framework, поддерживают создание и использование этих классов. В чем преимущество этого? Мои идеи:

  • Ошибки во время компиляции, в которых ошибки могли бы остаться незамеченными до времени выполнения. employeeData[0].Rows[i]["Name"] не так хорош, как employees[i].Name, где employees - это IEnumerable<Employee>
  • В C # 3 и более поздних версиях - возможность использовать LINQ и классные методы расширения в IEnumerable<T> для гибкой фильтрации коллекций данных вместо необходимости создавать / изменять хранимую процедуру или запрос в базе данных для каждой агрегации / выбора, которые мне нужно сделать .
  • Исходный код легче хранить в SCM, чем в базе данных, что означает, что лучше хранить больше логики в исходном коде.
  • Такой парень, как я, который изучил CS, занимаясь локальными приложениями, чувствует себя более комфортно

С другой стороны, преобразование данных в классы .NET перед их отображением на экране - это шаг, который займет вычислительное время и не является строго обязательным. И у меня есть ощущение, что GridView и его соотечественники предпочтут привязку к DataView вместо IEnumerable<T>. Кроме того, база данных будет быстрее запрашивать и агрегировать данные, чем LINQ.

Какова причина подхода, одобренного POCO? Я здесь это освещал или что-то упустил?

1 Ответ

2 голосов
/ 23 мая 2011

Чтобы ответить на ваш конкретный вопрос кратко:

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

  • Пример: нужно настроить URLRewrite при изменении имени страницы? Одно центральное место для этого явно идеально.

Однако ...

Вы можете исключить большинство негативов, используя LINQ to SQL или, в более сложных случаях, другие ORM, такие как Entity Framework или nHibernate .

Прочитайте Часть 1 и Часть 2 из блога Скотта Гу о LINQ to SQL для некоторого вдохновения по этому вопросу.

  • С LINQ to SQL вы получаете преимущества без недостатков (которые вы упомянули), а также несколько дополнительных преимуществ.

И еще ...

В ситуациях, когда вам не требуется такого рода нетривиальная логика - вы также можете использовать SQLDataSource и привязывать напрямую к Gridview; однако LINQ to SQL настолько прост, что многие предпочитают его даже в самых простых случаях.

...