Надеюсь, я смогу сформулировать свой вопрос достаточно хорошо, чтобы получить здесь четкую и полезную обратную связь. У меня есть отчеты (например, бумажные отчеты) в моем приложении .NET, к которым привязаны данные. Как правило, отчеты представляют собой комбинацию множества элементов данных в нескольких бизнес-объектах, которые могут не все связаны через иерархию наследования и т. Д. Это затрудняет объединение всех необходимых данных для привязки к отчету.
Итак, что я сделал до того, как создать классы 'Report' с элементами данных, специфичными для поддержки отчетов, к которым они привязаны, а внутренняя часть может быть привязана к специально созданным хранимым процедурам, которые приносят это возврат данных (возможно, несколько объединений во многих таблицах для получения необходимых данных right ). Поэтому, если бы я хотел провести аналогию с миром баз данных, я, по сути, «денормализировал» структуру данных, чтобы собрать все эти данные в единый класс, чтобы упростить привязку к отчету.
Однако, исходя из жестких концепций ООП и дизайна архитектуры, можно сказать, что отчет - это просто еще одна «вещь» для привязки данных, и его класс не должен разрабатываться только для удовлетворения потребностей связывания данных. В этом мыслительном процессе мне нужно было бы сделать так, чтобы дизайн моего класса мог создавать отношения, необходимые для правильного объединения всех данных, чтобы они все еще были связаны, но не создавать специальные классы 'Report'. Мне иногда трудно это сделать. Гораздо проще создать эти отношения в серверных хранимых процедурах, а затем просто вывести набор результатов, чтобы почти сразу связать его с отчетом.
Так что же это за правильный способ решить эту проблему? Если я создаю эти специализированные классы отчетов без какого-либо поведения, я ввожу анти-паттерн, такой как Anemic Domain Model?
Я мог бы использовать некоторую обратную связь, и, пожалуйста, говорите, если мой вопрос и сценарии не имели смысла. Спасибо!