Объединение определенных пользователем агрегатов (например, количества SQL) с «чистыми» объектами модели?

Question

Какова лучшая практика введения пользовательских (обычно изменчивых) данных в классы модели сущностей? Сначала это может звучать как плохая практика, но, похоже, это довольно распространенный сценарий. В нашем недавнем веб-приложении мы разработали правильную модель, и в большинстве случаев мы справляемся с загрузкой сущностей модели. Но есть случаи, когда мы не можем позволить себе загрузить целую иерархию объектов; нам нужно загрузить, скажем, результаты пары SQL COUNT или, возможно, некоторую дополнительную информацию вместе (или встроенную внутри) с объектами модели. Таким образом, в основном, требования и условия:

<Ол>

Это веб-приложение, в котором 99,99999999999% всех операций являются операциями чтения.

Им не нужно обрабатывать или выполнять какую-либо сложную бизнес-логику. Нам просто нужно быстро получить данные в HTML.

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

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

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

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

Answer 1

Если вы просто получаете реляционные данные в браузер и из него, с небольшим или отсутствующим поведением между ними, это звучит как попытка решить реляционную проблему с помощью парадигмы ОО.

Я мог бы вообще отказаться от объектно-ориентированного подхода.

Команда разработчиков недавно переписала приложение, спросив "Какова самая простая вещь, которая может работать?" и "Какой язык ближе к проблеме?" Наше новое приложение, заменяющее OO, оказалось в 10 раз меньше, быстрее и дешевле.

Мы использовали SQL, хранимые процедуры, библиотеки XML на сервере БД, XSLT (для получения HTML) и JavaScript.

Answer 2

ООП-пурист, как и я, пошел бы к шаблону Decorator. http://en.wikipedia.org/wiki/Decorator_pattern

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

Answer 3

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

Они могут вызывать " живые " результаты, которые отображаются непосредственно в строки базы данных и поэтому могут быть отредактированы и "сохранены".

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

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