Какой из них вы предпочитаете для поиска / отчетности DataTable или DTO или класса домена?

Question

Проект, в котором я сейчас работаю, требует много страниц поиска / фильтрации. Например, у меня есть сложная страница поиска, чтобы получить вопросы по данным, категории, единице, ...

Issue Domain Class является сложным и содержит множество объектов-значений и дочерних объектов.

. Мне интересно, как люди справляются с поиском / фильтрацией / отчетностью для пользовательского интерфейса. Насколько я знаю, у меня есть 3 варианта, но ни один из них не делает меня счастливее.

1.) Отправка параметров в репозиторий / DAO для получения DataTable и привязки DataTable к элементам управления пользовательского интерфейса. Например, для ASP.NET GridView

DataTable dataTable =issueReportRepository.FindBy(specs);
.....
grid.DataSource=dataTable;
grid.DataBind();

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

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

2.) Отправьте параметры в репозиторий / DAO для получения DTO и привязки DTO к элементам управления пользовательского интерфейса.

IList<IssueDTO> issueDTOs =issueReportRepository.FindBy(specs);
....
grid.DataSource=issueDTOs;
grid.DataBind();

В этом параметре то же, что и выше, но мне нужно создавать анемичные объекты DTO для каждой страницы поиска. Также для разных страниц поиска проблем я должен показать разные части объектов проблем. IssueSearchDTO, CompanyIssueTO, MyIssueDTO ....

3.) Отправьте параметры в класс Real Repository, чтобы получить полностью сконструированные доменные объекты.

IList<Issue> issues =issueRepository.FindBy(specs);
//Bind to grid...

Мне нравится доменный дизайн и шаблоны. В этой опции нет DTO или логики дублирования. Но в этой опции мне нужно создать много дочерних и ценностных объектов, которые не будут отображаться в пользовательском интерфейсе. Также для этого требуется полное объединение лота, чтобы получить полный объект домена и стоимость производительности для дочерних игл. объекты и объекты стоимости.

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

Какой из них вы предпочитаете? Или я делаю это неправильно? Есть какие-нибудь предложения или лучший способ сделать это?

Answer 1

У меня есть несколько предложений, но, конечно, общий ответ «это зависит».

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

Во-вторых, реализация отложенной загрузки вручную является относительно простой, поэтому в случае, если вы не собираетесь использовать инструмент ORM, вы можете просто создать свойства для ваших объектов, которые будут выглядеть примерно так:

private Foo _foo;
public Foo Foo
{  
  get {  
         if(_foo == null)
         {
            _foo = _repository.Get(id);
         }
         return _foo;
       }
}

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

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

Answer 2

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

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

Я борюсь с этим и во многих моих приложениях, и реальность такова, что # 2 - лучший компромисс между временем и дизайном. Теперь, если вы спрашиваете об объектах вашего бизнеса и всех их потребностях, возникает вопрос нет о том, что полностью выстроенная и правильно спроектированная модель важна и ее не существует. Однако когда дело доходит до сообщения и поиска этого для меня, это другое животное. # 2 предоставляет строго типизированные данные в анемичных классах и не так примитивен, как жестко закодированные значения в DataSets, как # 1, и все еще значительно сокращает время, необходимое для завершения проектирования, по сравнению с # 3.

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

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