Как Разделение запроса команды (CQS) реализовано при использовании ORM?
Необходимо определить обработчики исключений. Смотрите на http://dev.mysql.com/doc/refman/5.0/en/declare-handler.html
4 ответа
Я предполагаю, что под CQS вы имеете в виду архитектурный шаблон DDD, известный как CQRS , а не строго традиционный принцип CQS .
Я бы по-прежнему используйте NHibernate для своей модели только для чтения. Есть много преимуществ, таких как будущие и множественные запросы, ленивая / нетерпеливая загрузка и т. Д., Которые оптимизируют болтовню БД. Кроме того, будет легче составлять запросы с помощью ORM, если пользовательский интерфейс позволяет пользователю существенно изменять предложение where.
Что касается того, как технически обрабатывать модель только для чтения, вы можете пометить объект неизменным ] с помощью NHibernate. Вы можете просто пометить все прочитанные вами объекты модели как неизменяемые. Кроме того, я не Не думаю, что вы можете обновлять прогнозы в NHibernate, так что это еще один вариант, который можно использовать в качестве модели только для чтения (кто-нибудь, пожалуйста, поправьте меня, если я ошибаюсь, поскольку я не уверен на 100%).
Относительно уродливых или невозможных сопоставлений NH: NH может отображаться на представления и хранимые процедуры, поэтому я думаю, что было бы хорошо использовать их, когда вам нужно. Представления, вероятно, немного более гибкие, чем хранимые процедуры для сценария только для чтения, поскольку ваш SQL по-прежнему будет динамическим. Однако, если вам нужно чтение / запись для любой из этих плоских структур, я бы сопоставил ее с процедурой хранения.
Однако, если вам нужно чтение / запись для любой из этих плоских структур, я бы сопоставил ее с процедурой хранения. Однако, если вам нужно чтение / запись для любой из этих плоских структур, я бы сопоставил ее с процедурой хранения.Нет необходимости использовать другой подход к чтению вашей базы данных по сравнению с обновлением вашей базы данных. CQS просто заявляет, что команды, обновляющие хранилище данных, должны быть отделены от запросов, считывающих состояние из хранилища данных.
Вы все еще можете использовать NHibernate для чтения из вашего хранилища данных, но вы можете сделать это очевидным, создав два различные классы для инкапсуляции вашего доступа к данным. Один класс будет иметь методы для чтения (запроса) хранилища данных, другой класс будет иметь методы для выдачи команд (добавления, обновления, удаления) хранилищу данных.
Вы пытаетесь избежать метода, который получает сообщение из базы данных, а затем помечает сообщение как прочитанное в базе данных. Это должны быть два разных вызова метода. Вы не должны изменять состояние и возвращать значение одним и тем же методом.
Я Джек Fiddler Fiddler в середине, запустите запрос браузера и .NET-запрос один за другим и убедитесь, что вы действительно получите то, что вы думаете. Возможно, есть перенаправление или что-то еще, что Hinky продолжается (возможно, браузер предварительно добавляет «/», а .NET ждет для передирата и т. Д.), Несмотря на не сразу. Я построил огромные приложения на клиенте .NET HTTP с тем, что вы описываете - что-то еще должно происходить.
Что произойдет, если вы придерживаетесь «/» в конце URL?
-121--3383596-Это хорошая статья для объяснения философии VIM.
-121--4104000-Мы используем EF для командной части, а также прямой ADO.NET => DTOS для цепочки запросов. Преимущества:
1) Возможность оптимизации запросов SQL и использовать расширенные функции магазина DB, не абстрагируемые в ORM-слое
2) меньше накладных
, но мы используем разделение только для требовательных частей (поиск), остальных полагается на общую структуру объекта.
В конечном счете, идея заключается в том, что вы должны использовать то, что делает канал Query наиболее простым для вас в создании и поддержке. Вам больше не нужно беспокоиться об обновлениях, внедрении бизнес-правил, поддержании целостности данных или даже обработке нагрузки (по большей части). Таким образом, вы можете выбирать многие варианты, которые ранее не были доступны.
Но NHibernate все еще может быть хорошим вариантом ... просто он больше не является автоматическим вариантом по умолчанию (что иногда бывает для командной стороны).
Мы решили использовать Castle Active Record (который основан на NHibernate под капотом), в основном потому, что у него есть хорошая функция, которая генерирует для вас таблицу из класса. Это отлично подходит для нас, потому что вот наш рабочий процесс: Сначала мы создаем класс ViewModel. Этот класс полностью формируется для нужд представления. Затем мы помечаем эту ViewModel атрибутами Castle Active Record. Затем мы просим Active Record сгенерировать соответствующую таблицу для этого класса в базе данных Query. Это самый быстрый и гладкий способ, который мы нашли, чтобы быстро получить таблицу базы данных Query, которая обслуживает класс ViewModel. Автоматическая генерация отражает реальность того, что единственная причина существования таблицы - это обслуживание представления.