Практический объектно-ориентированный вопрос проектирования

Question

Я перехожу на более объектно-ориентированный подход к ASP.NET веб-приложениям в новой системе, которую я разрабатываю.

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

В представлении отдела я перечисляю все курсы, принадлежащие отделу, и мне нужны агрегированные цифры для каждого курса, такие как количество поступивших, изъятых, количество мужчин / женщин и т. Д.

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

И затем отдельный вид студента, где отображаются все сведения о студенте, включая зачисления на другие курсы, адрес и т. Д.

Раньше у меня был бы уровень доступа к данным, который возвращал бы все данные, которые мне были нужны в каждом случае, и возвращал их как SQLDataReader или DataSet (работающий в VB.NET). Теперь я пытаюсь смоделировать это в объектно-ориентированном подходе. Я создаю объекты в DAL и возвращаю их в BLL . Я не уверен, как справиться с этим, хотя, когда мне нужны агрегированные детали в объектах. Например, в представлении отдела со списком курсов у меня будут агрегаты для каждого из курсов. Буду ли я хранить коллекцию некоторых легких объектов курса в отделе, где эти легкие объекты курса будут хранить агрегированные значения?

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

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

Answer 1

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

class CourseStats
    string Name { get; }
    int Enrollments { get; }
    int Withdrawals { get; }

SQL для агрегации довольно прост. Однако убедитесь, что вы используете ORM (например, NHibernate ) или менее сложный инструмент Result-Set Mapper (например, BLToolkit ): вам не нужно вручную увлажнять эти объекты.

Дополнительным преимуществом является то, что вы можете кэшировать оба результата запроса (и аннулировать кеш, как только что-то связано с курсом).

Answer 2

Это на самом деле довольно большая проблема, с которой многие люди борются.

Насколько мне удалось определить, есть по крайней мере две школы мысли по этому вопросу:

• Постоянные невежественные доменные объекты с OR / M, который поддерживает отложенную загрузку
• Домен-управляемый дизайн и явно смоделированные (и явно загруженные) агрегаты

У Джереми Миллера есть статья в журнале MSDN , в которой рассматриваются некоторые закономерности постоянства.

В книге Домен-управляемый дизайн есть хорошее обсуждение моделирования агрегатов.

Answer 3

Если вы работаете с .NET, вам следует изучить одну вещь: LINQ to SQL .Это позволит вам иметь очень элегантный интерфейс в вашем DAL.LINQ позволит вам создавать агрегированных запросов в вашей BLL, что позволяет сохранить сантехнический код, а также неприятные фрагменты SQL, разбросанные по всему источнику.Пример из предыдущей ссылки совокупного запроса SQL, выраженного с помощью LINQ:

var averageOrderTotals =
  customers.
  Select(c => new {
      c.Name,
      AverageOrderTotal = c.Orders.Average(o => o.Total)
   });

Я переключил свой уровень базы данных на LINQ, хотя в моем случае я не использую MS SQL Server, поэтому вместо этогоиспользовал библиотеку DbLinq .

Самое последнее, что вы хотите сделать, - это изменить ваши классы в соответствии с уровнем доступа к вашей базе данных. Такой подход сделает ваше решение очень хрупким.

Answer 4

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

Альтернативным подходом может быть запуск сумм для базы данных с помощью некоторого пользовательского собственного SQL. Вы можете скрыть это в DAL. DAL затем возвращает, например, виртуальный курс (которого нет в базе данных, но который содержит суммы).

Третий подход - хранить эти значения где-то в объекте отдела и обновлять их при каждом изменении / добавлении / удалении курса.