Разработка приложения для базы данных с изменением схемы

Question

Я работаю над приложением ASP.NET MVC, которое по сути является веб-инструментом отчетности. База данных, из которой я извлекаю свои отчеты, все еще находится в разработке, т. Е. Ее схема может измениться, но если это произойдет, она должна измениться лишь в минимальной степени.

Вместо того чтобы ждать, пока схема базы данных станет конкретной, я решил, что теперь я могу определять свои модели данных как POCO и использовать интерфейс хранилища для извлечения данных (вместе с Ninject для IoC). Таким образом, теперь я могу построить свои модели представления отчетов с использованием тестовых данных, а затем внедрить свои репозитории для использования реальной базы данных, в идеале без необходимости изменения моей модели -> сопоставления модели представления.

Первый вопрос связан с терминологией: поскольку это приложение для отчетов, мое взаимодействие с БД доступно только для чтения. Является ли хранилище правильным термином для использования здесь?

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

Answer 1

мое взаимодействие с БД доступно только для чтения.Является ли хранилище правильным термином для использования здесь?

Не совсем.Репозиторий - это, по сути, фасад, работающий между вашим основным поставщиком данных и любым кодом, который его потребляет, показывая все операции, которые вы делаете доступными, обычно через интерфейс.Обычно он включает в себя базового поставщика (EF, NHibernate и т. Д.), Поэтому потребляющий код не имеет представления о том, как реализован механизм персистентности.

Тот факт, что вы хотите, чтобы он был «только для чтения», является проблемой реализации.Если вам не нужно делать какие-либо записи, я бы даже не стал заниматься ORM.Это излишне.Просто используйте хранимые процедуры и, если хотите, оберните их простым компонентом, таким как Massive или Dapper .Затем вы можете представить эти хранимые процедуры через очень простой репозиторий, который просто предоставляет эти запросы, и ничего больше.На всякий случай, если вы хотите переключиться на что-то еще, как классический ADO.NET.

Использование SPROC дает дополнительное преимущество , вы можете подделать результаты хранимой процедуры.Например, не заставляйте его переходить к фактическим таблицам, вместо этого имитируйте наборы результатов таким образом, чтобы результат был тем, что вы ожидаете.

Затем, когда схема будет готова, обновите SPROC, и ваши тесты должнывсе еще проходит, если вы правильно подделали.Конечно, если требуются новые поля, возможно, потребуется изменить код.Но использование SPROC здесь означает, что ваши запросы будут очень быстрыми (без вздутия ORM, близко к металлу), и это также поможет вашему сценарию здесь.

Я могу быть атакован «хранимыми процедурами доисторическими»последователи, но это то, что я бы сделал в вашем сценарии.