Действительно ли NHibernate SchemaUpdate безопасен в производственном коде?

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

Мой вопрос состоит в том, достаточно ли это надежно для отъезда в производственном коде. Очевидно, это не должно работать каждый раз, когда программа запускается в продуктивной среде, но это было бы полезно для возрастающих обновлений продукта (хотя я не планирую внесение никаких существенных изменений в домен после поставок продукта).

(Возможно, мой реальный вопрос должен состоять в том, как безопасный это должно использовать эти два инструмента в соединении?)

Обновление

Приложение имеет две версии: автономный рабочий стол и многопользовательский клиент/сервер. Также из-за природы бизнес-домена (налоговое программное обеспечение) у меня есть роскошь запуска с чистой базы данных каждый год.

14
задан Kenneth Cochran 14 January 2010 в 17:06
поделиться

4 ответа

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

Один только должен удержать вас от этого подхода, независимо от качества / надежности кода Nhibernate.

13
ответ дан 1 December 2019 в 08:42
поделиться

Это зависит от того, насколько критически ваши данные! Я сомневаюсь, что это такая хорошая идея для банковской системы. У меня не было проблем с обновлением отдельно от одной вещи. Иногда это не переименовано правильно. Дальше большее, это уровень безопасности, соединяющий с учетной записью, которая может изменить такую ​​схему :)

2
ответ дан 1 December 2019 в 08:42
поделиться

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

Другими словами, абсолютно не для использования в производстве.

8
ответ дан 1 December 2019 в 08:42
поделиться

После запуска клиентской утилиты вы получите файл XXXXService.cs и output.config.

Если вы наблюдаете за классом XXXXService, у вас есть все в файле. Их можно разделить как отдельный файл IXXXService и XXXService и файл datacontracts.

Затем можно запустить утилиту для второй службы и добавить файл IXXXService1.cs и 1XXXService.cs, а также те же данные, которые можно использовать для совместного использования этих 2.

Я не уверен, сможет ли это ответить на ваш вопрос. У меня был пример , который может вам помочь. Вы можете увидеть еще несколько примеров здесь , связанных с некоторыми вещами MVC и WCF.

-121--2995521-

Ну, без сомнения, я странный человек, но для настольных приложений (не веб) вот что я делаю. Я считаю почти любое приложение просто прославленным редактором. То есть, он имеет структуру данных, которая должна быть постоянной, и пользовательский интерфейс, чтобы позволить пользователю поместить информацию в эту структуру данных и извлечь ее.

Структура данных должна быть простой, простой и простой. Я считаю, что это просто хранилище информации, с как можно меньшей избыточностью. Я не хочу строить структуру данных, которая существует для того, чтобы быть видимым проявлением базовых данных, таких как древовидные элементы управления и т.д., потому что тогда это должно быть согласовано с базовыми данными, и вы получите все вопросы о том, как сохранить избыточные данные согласованными. (Пример: для графики не строить его, рисовать .) Если я не могу избежать создания избыточной структуры данных, я остаюсь как можно дальше от программирования в стиле уведомлений, которое пытается поддерживать избыточную структуру данных в тесном согласии. Из этого вытекает большая часть проблем с буглистом и производительностью. Скорее я предпочитаю свободную связь, где определенная степень несогласованности может быть допустима и управляется процессами, которые выполняются один раз в раз для продвижения изменений.

Для пользовательского интерфейса я был большим верующим в кодирование пользовательского интерфейса в стиле ООП и MVC, пока не обнаружил это в 1986. Теперь я испорчен, и я могу получить сложные пользовательские интерфейсы, закодированные за часть времени, которое возможно обычным стилем обработки событий управления, и они тривиальны, чтобы изменить по мере изменения требований. Но пока я в компании, может быть, только 3 человек в мире, которые его используют, потому что это точно не мейнстрим.

-121--2291550-

Я бы не стал рисковать. Что хорошо работает, это запустить его на промежуточном сервере, который был восстановлен из производства, а затем использовать инструмент сравнения базы данных (например, Red Gate), чтобы проверить изменения и создать сценарий.

9
ответ дан 1 December 2019 в 08:42
поделиться
Другие вопросы по тегам:

Похожие вопросы: