Для большинства приложений CRUD я использую генератор guid.comb
ID от NHibernate. Преимуществом этого является то, что у меня есть доступ к идентификатору до того, как я выполню очистку базы данных, и я обошел проблему фрагментации индекса, связанную с использованием обычных Guids.
Когда мы представляем обмен сообщениями, возникает несколько вопросов:
- Поскольку мы отправляем команды для внесения изменений в наш уровень домена, на самом деле у нас нет доступа к «новому» объекту домена в пользовательском интерфейсе. Часто (в случае веб-приложения) нам нужен его идентификатор для перенаправления на другую страницу. Одним из решений было бы передать идентификатор как часть команды (например, Guid.NewGuid ()), но тогда мы потеряем последовательные Guids, которые предоставляет NHibernate.
- Если вместо этого мы используем стратегию идентификации, мы устраняем проблему с индексами, но теперь у нас нет простого способа определения идентификатора из пользовательского интерфейса, кроме подписки на событие или синхронного выполнения команды, оба из которых не идеальны в сети. применение.
Так что мне любопытно, какую стратегию используют другие разработчики NServiceBus. Выполнение какой-либо операции над существующим объектом на самом деле не является проблемой, поскольку мы можем просто отправить запрос с помощью ajax для отправки команды и уведомить пользователя, что все прошло успешно (возможно). Поскольку страница, на которой они находятся, уже содержит обновленную информацию, этого достаточно.
Однако, когда мы создаем новый экземпляр объекта домена (с помощью команды), нам часто нужно перенаправить пользователя на страницу, которая затем извлекает вновь созданный объект из нашей базы данных. Конечно, эта сущность еще не сохранена (поскольку мы обрабатываем наши команды асинхронно), и нам обычно требуется Id для выполнения этого перенаправления.