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

Question

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

1. Это веб-приложение, где +99,9999999999% всех операций операции чтения.

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

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

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

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

Редактировать: Поскольку я позже понял, что вопрос был не очень хорошо сформирован, я решил переформулировать его и начать new one.

Answer 1

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

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

Я недавно переписал заявку, спросив: «Какая самая простая вещь, которая может работать?» и «Каков ближайший язык к проблеме?». Наше новое приложение, заменив OO, оказалось в 10 раз меньше, быстрее и дешевле.

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

Answer 2

Пурист ООП, как и я, пойдет в узор Декоратора. http://en.wikipedia.org/wiki/Decorator_pattern

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

Answer 3

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

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

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

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