Importation de données à partir d'une source de données tierce (conception d'architecture ouverte)

Question

Comment concevoir une application (classes, interfaces dans la bibliothèque de classes) dans .NET lorsque nous avons une conception de base de données fixe de notre côté et que nous devons prendre en charge les importations de données sources de données tierces, qui seront probablement en XML?

Par exemple, nous disons que nous avons dans notre DB une table de produits qui comporte des colonnes Id Titre Description de TaxLevel Prix

et de l'autre côté, nous avons par exemple les produits: ProductId ProdTitle Texte Prix de base Quantité.

Actuellement, je le faire comme ceci: Avoir le XML tiers convertir en cours et et de XSD puis désérialiser son contenu dans des objets typés forts (ce que nous obtenons à la suite de ce processus est des classes comme ThirdPartyProduct, ThirdPartyClassification, etc.).

, j'ai des méthodes comme celle-ci:

InsertProduct(ThirdPartyProduct newproduct) 

Je ne me interfaces pour le moment mais je voudrais. Ce que je voudrais, c'est implémenter quelque chose comme

public class Contoso_ProductSynchronization : ProductSynchronization 
{ 
    public void InsertProduct(ContosoProduct p) 
    { 
     Product product = new Product(); // this is our Entity class 
     // do the assignments from p to product here 

     using(SyncEntities db = new SyncEntities()) 
     { 
      // .... 
      db.AddToProducts(product); 
     } 
    } 

    // the problem is Product and ContosoProduct have no arhitectural connection right now 
    // so I cannot do this 
    public void InsertProduct(ContosoProduct p) 
    { 
     Product product = (Product)p; 

     using(SyncEntities db = new SyncEntities()) 
     { 
      // .... 
      db.AddToProducts(product); 
     } 
    } 
} 

où ProductSynchronization sera une interface ou une classe abstraite. Il y aura très probablement de nombreuses implémentations de ProductSynchronization. Je ne peux pas coder en dur les types - classes comme ContosoProduct, NorthwindProduct pourrait être créé à partir du XML tiers (de préférence je continuerais à utiliser la désérialisation).

J'espère que quelqu'un comprendra ce que j'essaie d'expliquer ici. Imaginez que vous êtes le vendeur et vous avez de nombreux fournisseurs et chacun utilise son propre format XML propriétaire. Cela ne me dérange pas le développement, qui sera bien sûr nécessaire chaque fois qu'un nouveau format apparaît, car il ne faudra que 10 à 20 méthodes pour être implémentées, je veux juste que l'architecture soit ouverte et supporte cela. Dans vos réponses, veuillez vous concentrer sur le design et pas tellement sur les technologies d'accès aux données car la plupart sont assez simples à utiliser (si vous avez besoin de savoir, EF sera utilisé pour interagir avec notre base de données).

Answer 1

[EDIT: Design Note]

Ok, du point de vue de la conception que je ferais xslt sur le xml entrant pour le transformer en un format unifié. Aussi très facile de vérifier le résultat xml vers un schéma. En utilisant xslt Je resterais loin de toute interface ou classe abstraite, et juste avoir une implémentation de classe dans mon code, la classe interne. Cela garderait la base de code propre, et les xslt eux-mêmes devraient être assez courts si les données sont aussi simples que vous le dites.

La documentation des transformations peut facilement être effectuée partout où vous avez la documentation de votre projet. Si vous décidez que vous voulez absolument avoir une classe par xml (ou si vous avez peut-être un .net dll au lieu de xml d'un client), alors je ferais hériter une classe d'interface ou une classe abstraite (basée sur votre classe interne et implémentez les mappages par propriété selon les besoins dans les classes de proxy.De cette façon, vous pouvez lancer n'importe quelle classe dans votre classe de base/interne.

Mais il me semble que la conversion/mappage en code rendra la conception du code un peu plus compliquée.

[Réponse originale]

Si je vous comprends bien, vous voulez mapper une classe ThirdPartyProduct vers votre propre classe interne. Au départ, je pense à la cartographie de classe. Utilisez quelque chose comme Automapper et configurez les mappages lorsque vous créez votre proxy de désérialisation XML. Si vous effectuez votre désérialisation avec les mêmes noms de propriété que votre classe interne, il y a moins de config à faire pour le mappeur. Convention sur la configuration.

Je voudrais entendre des pensées d'anyones sur aller cette route.

Une autre approche serait d'ajouter un .ToInternalProduct(ThirdPartyClass) dans une classe Converter. Et continuez d'ajouter plus que vous ajoutez plus de classes externes.

La troisième approche est pour les gars XSLT. Si vous aimez XSLT, vous pouvez transformer le XML en quelque chose qui peut être désérialisé dans votre classe de produit interne.

Lequel de ces trois que je choisirais dépendrait des compétences du programmeur, et qui continuerait à ajouter de nouvelles classes externes. L'approche XSLT ne nécessiterait aucune recompilation ou compilation du code au fur et à mesure de l'arrivée de nouveaux formats. Cela pourrait être un avantage.