Prism Modules and databases

I'm busy learning Prism开发者_Go百科 4 and the in and outs of everything, but I've yet to see a tutorial/walk through on what I want to accomplish. Hoping someone here has or has worked on a similar project.

My application is a basic CRUD application that I've broken down in to separate areas of concern and hence modules. However, I want all the modules to share one common local SQL Express database. The database will start off with just a limited number of tables to start with and each module will check the database for the tables it needs and if they are not there, create them. How can I go about accomplishing this?

I've thought about just adding in all my tables initially but this seems to break the principal of modularity in my mind. Perhaps my thinking is wrong, but what would be the point of loosely coupled modules if the database is already fully aware and strongly coupled to a given module from db creation?

Looking for some insight.

You seem to be asking two questions. The first is: How can I use PRISM to ensure that my module specific schema exists in the database, and if not, create it. The second question is: how can I best structure my data layer such that it is decoupled in a modular application.

To answer your first question about how to do the module schema check, I say this:

If you’ve been going through Prism, you’ve no doubt thought up a couple of ways to accomplish it. As with anything in programming, there are many ways to accomplish it. If I needed to do this with Prism, I’d probably do the following: Create a class (MyPlugInModule.cs) in my module assembly which implements the Microsoft.Practices.Prism.Modularity.IModule interface. I would then put code in either the constructor, or in the Initialize method, which checks the database to see if the module schema exists. If it does not, then create it.

To answer your second question about how to best structure your data modularity, I say this:

Like Goblin says, it really depends on what type of modularity you are trying to accomplish. If you are selling this application and you want to sell modules as independent packages, then you probably do not want to create a data model to support a package until the end user has paid for it.

You should be able to use Entity Framework to ensure that your modules are able to share entities with the base application modules. Additionally, depending on what your requirements are, or if your architecture will allow, you may want to abstract your model/data layer into assemblies that are not perfectly aligned with your modules. This will reduce code duplication and dependencies.

On an application that I am currently working on, we're using WPF with MVVM, PRISM with MEF, and WCF data services. Our client modules share a data assembly which communicates with our main data service endpoint that sits on top of the base application model (authentication/role tables, application data, etc). When tables in our database are created that are specific to the domain of a module, a new model and service endpoint are created on the server, and a separate assembly is created on the client to communicate with the data model.

If the module specific model changes, only the affected components have to be changed, since module specific data is encapsulated in its own service and client assembly. It is a better option from an isolation standpoint for testing, security, etc. The downside of course is if the base application model changes, all of the associated module specific implementations have to be updated.

But again, it really depends on your requirements. If you stick with PRISM 4 with MEF, modular design patterns, and entity framework 4, you should be able to come up with a good solution that is modular without being tightly coupled.

If your modules are truly independent - how about a database per module? If you need foreign keys between your modules - they are in essense not really encapsulated - and I'd put the whole database into play from the get-go. Much easier to keep the schema up-to-date betweeen updates.

Modularity comes in many flavours - business-perspective (pay-per-module), modularity in terms of responsibilities etc. etc.

My 5 cents :)

This response is for anyone coming here that wants to see code that hooks up a local database. It works for me, not sure if it's best practice or not.

I'm using prism and I needed to get my database working. Here is what I did. The Entity Framework seems to "just work" for putting the database somewhere.

Bootstrapper.cs file:

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

My AppDatabaseContext.cs file:

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
}

In one of my ViewModels:

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