Призма Модули и базы данных

Question

Я занят изучением Prism 4 и всеми подробностями, но мне еще предстоит увидеть учебник / обзор того, чего я хочу достичь.Надеюсь, что кто-то здесь работал или работал над аналогичным проектом.

Мое приложение - это базовое приложение CRUD, которое я разбил на отдельные проблемные области и, следовательно, модули.Однако я хочу, чтобы все модули использовали одну общую локальную базу данных SQL Express.Для начала база данных будет иметь только ограниченное количество таблиц, и каждый модуль проверит базу данных на наличие необходимых ей таблиц и, если их нет, создайте их.Как я могу добиться этого?

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

Нужна некоторая информация.

Answer 1

Вы, кажется, задаете два вопроса. Первый: Как я могу использовать PRISM, чтобы убедиться, что схема моего модуля существует в базе данных, и, если нет, создать ее. Второй вопрос: как мне лучше структурировать мой слой данных таким образом, чтобы он был отделен в модульном приложении.

Чтобы ответить на ваш первый вопрос о том, как выполнить проверку схемы модуля, я скажу следующее:

Если вы проходили Призму, вы, без сомнения, придумали несколько способов ее достижения. Как и в чем-либо в программировании, есть много способов сделать это. Если бы мне нужно было сделать это с помощью Prism, я бы, вероятно, сделал следующее: Создайте класс (MyPlugInModule.cs) в сборке моего модуля, который реализует интерфейс Microsoft.Practices.Prism.Modularity.IModule. Затем я поместил бы код либо в конструктор, либо в метод Initialize, который проверяет базу данных, чтобы увидеть, существует ли схема модуля. Если это не так, то создайте его.

Чтобы ответить на ваш второй вопрос о том, как лучше структурировать вашу модульность данных, я скажу следующее:

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

Вы должны быть в состоянии использовать Entity Framework, чтобы ваши модули могли обмениваться сущностями с модулями базовых приложений. Кроме того, в зависимости от ваших требований или от того, позволит ли ваша архитектура, вы можете захотеть абстрагировать вашу модель / уровень данных в сборки, которые не полностью соответствуют вашим модулям. Это уменьшит дублирование кода и зависимости.

В приложении, над которым я сейчас работаю, мы используем WPF с MVVM, PRISM с MEF и службы данных WCF. Наши клиентские модули совместно используют сборку данных, которая взаимодействует с нашей основной конечной точкой службы данных, которая находится поверх базовой модели приложения (таблицы аутентификации / роли, данные приложения и т. Д.). Когда в нашей базе данных создаются таблицы, относящиеся к домену модуля, на сервере создаются новая модель и конечная точка службы, а на клиенте создается отдельная сборка для связи с моделью данных.

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

Но опять же, это действительно зависит от ваших требований. Если вы придерживаетесь PRISM 4 с MEF, шаблонами модульного проектирования и структурой сущностей 4, у вас должно получиться хорошее решение, которое является модульным, не будучи тесно связанным.

Answer 2

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

Модульность предлагается во многих вариантах - с точки зрения бизнеса (оплата за модуль), модульность с точки зрения обязанностей и т. Д. И т. Д.

Мои 5 центов:)

Answer 3

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

Я использую призму, и мне нужно, чтобы моя база данных работала.Вот что я сделал.Entity Framework, кажется, «просто работает» для размещения базы данных где-то.

Файл Bootstrapper.cs:

....
protected override void ConfigureContainer() {
    base.ConfigureContainer();
    // Register my navigation
    Container.RegisterType<IAppDatabaseContext, AppDatabaseContext>();
}
....

Файл My AppDatabaseContext.cs:

public class AppDatabaseContext : DbContext, IAppDatabaseContext {
    DbSet<MyModelOne> MyModelOnes { get; set; }
    DbSet<MyModelTwo> MyModelTwos { get; set; }
    DbSet<MyModelThree> MyModelThrees { get; set; }
}

public interface IAppDatabaseContext {
    DbSet<MyModelOne> MyModelOnes { get; set; }
    DbSet<MyModelTwo> MyModelTwos { get; set; }
    DbSet<MyModelThree> MyModelThrees { get; set; }

    int SaveChanges();
    // Other methods needed to use the DbContext
}

В одной из моих моделей представления:

public ConstructorMethod(IEventAggregator eventAggregator, IAppDatabaseContext dbContext) {
    _db = dbContext; // I then use this in my Observed Properties
}