Проектирование DLL уровня базы данных для поддержки замены вставки

Question

Мне интересно, есть ли разумный способ спроектировать C # dll, чтобы впоследствии можно было перестроить его и использовать новую версию в качестве замены в «безопасном» режиме.Безопасный в основном означает, что подписи не меняются.

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

Основные правила, которые я придумал, таковы:

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

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

Итак, имеет ли эта идея смысл?Есть ли какие-либо стратегии, которые следует использовать, чтобы сделать это достаточно безопасным (т. Е. Без добавления большого количества нового риска, помимо того, что связано с редактированием хранимых процедур без перестройки приложения)?

Answer 1

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

Обратите внимание, что мы НЕ внедрили LINQ или какой-либо другой инструмент ORM.Вместо этого в нашем коде DAL используется обычный доступ к базе данных, предоставляемый через Enterprise Library.

Ключ был в том, что в сборке есть как классы, так и «провайдеры», отвечающие за загрузку и сохранение классов.Когда мы сделаем изменение подписи s'proc, мы обновим соответствующую сборку.Иногда это требует добавления дополнительных полей в определение класса.

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

Тем не менее, это редкий день, когда изменения в нашей объектной модели не отражаются каким-либо образом в основной базе кода.(новые поля ввода, например).Изменения во внутренних процессах s'proc происходят достаточно часто, но они полностью обрабатываются в SQL и не требуют обновления DAL.

Answer 2

То, что вы описываете, называется репозиториями, и они являются частью доменного дизайна. В сочетании с ORM (NHibernate, Entity Framework) это даст вам некоторую гибкость.

Однако у вас все равно будут проблемы. Когда вы получите новое поле в базе данных, ваша структура классов изменится, потому что вы получите новые открытые поля.

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