Prism Modules et bases de données

Question

Je suis très occupé à apprendre Prism 4 et tout ce qu'il y a à faire, mais je n'ai pas encore vu de tutoriel ou de didacticiel sur ce que je veux accomplir. En espérant que quelqu'un ici a ou a travaillé sur un projet similaire.

Mon application est une application CRUD de base que j'ai décomposée pour séparer les domaines de préoccupation et donc les modules. Cependant, je souhaite que tous les modules partagent une base de données SQL Express locale commune. La base de données commencera avec juste un nombre limité de tables pour commencer et chaque module vérifiera la base de données pour les tables dont il a besoin et si elles ne sont pas là, créez-les. Comment puis-je y arriver?

J'ai pensé à simplement ajouter dans mes tables tout d'abord mais cela semble briser le principe de la modularité dans mon esprit. Peut-être que ma pensée est fausse, mais quel serait le but des modules faiblement couplés si la base de données est déjà pleinement consciente et fortement couplée à un module donné de la création db?

Vous cherchez un aperçu.

Answer 1

Vous semblez se poser deux questions . La première est: Comment puis-je utiliser PRISM pour m'assurer que mon schéma spécifique au module existe dans la base de données, et sinon, le créer. La deuxième question est: comment puis-je structurer au mieux ma couche de données de manière à la découpler dans une application modulaire.

Pour répondre à votre première question sur la façon de faire la vérification du schéma du module, je dis ceci:

Si vous avez été en passant par Prism, vous avez sans doute imaginé deux façons d'y parvenir. Comme avec n'importe quoi dans la programmation, il y a beaucoup de manières de l'accomplir. Si j'avais besoin de faire cela avec Prism, je ferais probablement ce qui suit: Créer une classe (MyPlugInModule.cs) dans mon assembly de module qui implémente l'interface Microsoft.Practices.Prism.Modularity.IModule. Je mettrais alors du code dans le constructeur, ou dans la méthode Initialize, qui vérifie la base de données pour voir si le schéma du module existe. Si ce n'est pas le cas, créez-le.

Pour répondre à votre deuxième question sur la façon de structurer au mieux votre modularité de données, je dis ceci:

Comme Goblin dit, cela dépend vraiment de quel type de modularité que vous essayez d'accomplir. Si vous vendez cette application et que vous souhaitez vendre des modules en tant que packages indépendants, vous ne souhaiterez probablement pas créer de modèle de données pour prendre en charge un package tant que l'utilisateur final ne l'a pas payé.

Vous devriez être en mesure d'utiliser Entity Framework pour vous assurer que vos modules peuvent partager des entités avec les modules d'application de base. De plus, en fonction de vos besoins ou si votre architecture le permet, vous pouvez vouloir extraire votre couche de données/modèle dans des assemblages qui ne sont pas parfaitement alignés avec vos modules. Cela réduira la duplication de code et les dépendances.

Dans une application sur laquelle je travaille actuellement, nous utilisons WPF avec MVVM, PRISM avec MEF et les services de données WCF.Nos modules clients partagent un ensemble de données communiquant avec notre point de terminaison de service de données principal qui se trouve au-dessus du modèle d'application de base (tables d'authentification/rôle, données d'application, etc.). Lorsque des tables dans notre base de données sont créées et spécifiques au domaine d'un module, un nouveau noeud final de modèle et de service est créé sur le serveur et un ensemble distinct est créé sur le client pour communiquer avec le modèle de données.

Si le modèle spécifique au module change, seuls les composants concernés doivent être modifiés, car les données spécifiques au module sont encapsulées dans son propre ensemble de service et client. C'est une meilleure option du point de vue de l'isolation pour les tests, la sécurité, etc. L'inconvénient est bien sûr que si le modèle d'application de base change, toutes les implémentations spécifiques au module doivent être mises à jour.

Mais encore une fois, cela dépend vraiment de vos besoins. Si vous respectez PRISM 4 avec MEF, les modèles de conception modulaires et entity framework 4, vous devriez être capable de trouver une bonne solution qui soit modulaire sans être étroitement couplée.

Answer 2

Si vos modules sont vraiment indépendants - que diriez-vous d'une base de données par module? Si vous avez besoin de clés étrangères entre vos modules - elles ne sont pas vraiment encapsulées - et je mettrais toute la base de données en jeu dès le départ. Beaucoup plus facile de garder le schéma à jour entre les mises à jour.

Modularité est disponible en plusieurs saveurs - affaires perspective (pay-per-module), la modularité en termes de responsabilités, etc., etc.

Mes 5 cents :)

Answer 3

Cette réponse est pour toute personne venant ici qui veut voir le code qui relie une base de données locale. Cela fonctionne pour moi, pas sûr si c'est la meilleure pratique ou non. J'utilise le prisme et je devais faire fonctionner ma base de données. Voici ce que j'ai fait. Entity Framework semble «juste fonctionner» pour mettre la base de données quelque part.

fichier Bootstrapper.cs:

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

Mon fichier 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 
} 

Dans un de mes ViewModels:

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