2NetFly
-
MCV – добавление еще одного слоя
При разработке приложений среднего и выше среднего уровня сложностей для реализации модели зачастую используют модель предметной области. При использовании РСУБД это влечет за собой необходимость создания прослойки между базой данных и конечными классами модели, которую реализуют в виде некоторого гетвея, ORM etc. Преимущества такого подхода всем известны, думаю, известны и недостатки. Самая большая проблема, с которой сталкиваюсь лично я - невозможность эффективного взаимодействия представления с моделью в том случае, когда мне нужно получить и отобразить данные. Тривиальный случай - выборка с 3-4 джоинами из таблиц, которые "представлены" различными классами модели. Нетривиальный – вложенные запросы, запросы с объединениями и т.д. Даже ORM, насколько я могу судить после изучения всей русскоязычной литературы, представленной в сети, не умеет решать подобных задач, а OQL еще не настолько гибок и селен, чтоб конкурировать с SQL. Мне попадались решения, в которых использовались разнообразные дополнительные слои и классы, однако, затраты на их реализацию чрезмерно высоки, а рациональность использования - сомнительна.
Я склоняюсь к выводу, что сейчас не существует средств, которые способны заменить "raw SQL|. Как я уже говорил выше, чаще всего с проблемой выполнения сложных запросов приходится сталкиваться решая задачи отображения данных (выполнение select запросов). Почему бы не поступить следующим образом: создать дополнительный слой, содержащий классы с методами, выполняющими сложные запросы и возвращающие данные контроллеру или сразу же в представление в удобном формате (коллекция, массив ссылок на хеш и т.д.). Научив классы сортировать, лимитировать и разделять на страницы полученные данные мы получим довольно сильный механизм. Конечно, он имеет свои недостатки, например, необходимость дублирования преобразования и форматирования полей, иногда приходится повторять некоторые вещи, реализованные в классах модели. Но по сравнению с тем, что приходится выдумывать в рамках стандартной концепции – это ерунда.
Что скажете по этому поводу? Как вы решаете подобные проблемы? Может уже существуют стандартные решения?
При разработке приложений среднего и выше среднего уровня сложностей для реализации модели зачастую используют модель предметной области. При использовании РСУБД это влечет за собой необходимость создания прослойки между базой данных и конечными классами модели, которую реализуют в виде некоторого гетвея, ORM etc. Преимущества такого подхода всем известны, думаю, известны и недостатки. Самая большая проблема, с которой сталкиваюсь лично я - невозможность эффективного взаимодействия представления с моделью в том случае, когда мне нужно получить и отобразить данные. Тривиальный случай - выборка с 3-4 джоинами из таблиц, которые "представлены" различными классами модели. Нетривиальный – вложенные запросы, запросы с объединениями и т.д. Даже ORM, насколько я могу судить после изучения всей русскоязычной литературы, представленной в сети, не умеет решать подобных задач, а OQL еще не настолько гибок и селен, чтоб конкурировать с SQL. Мне попадались решения, в которых использовались разнообразные дополнительные слои и классы, однако, затраты на их реализацию чрезмерно высоки, а рациональность использования - сомнительна.
Я склоняюсь к выводу, что сейчас не существует средств, которые способны заменить "raw SQL|. Как я уже говорил выше, чаще всего с проблемой выполнения сложных запросов приходится сталкиваться решая задачи отображения данных (выполнение select запросов). Почему бы не поступить следующим образом: создать дополнительный слой, содержащий классы с методами, выполняющими сложные запросы и возвращающие данные контроллеру или сразу же в представление в удобном формате (коллекция, массив ссылок на хеш и т.д.). Научив классы сортировать, лимитировать и разделять на страницы полученные данные мы получим довольно сильный механизм. Конечно, он имеет свои недостатки, например, необходимость дублирования преобразования и форматирования полей, иногда приходится повторять некоторые вещи, реализованные в классах модели. Но по сравнению с тем, что приходится выдумывать в рамках стандартной концепции – это ерунда.
Что скажете по этому поводу? Как вы решаете подобные проблемы? Может уже существуют стандартные решения?
)
