Question

How would you design an application (classes, interfaces in class library) in .NET when we have a fixed database design on our side and we need to support imports of data from third party data sources, which will most likely be in XML?

For instance, let us say we have a Products table in our DB which has columns
Id
Title
Description
TaxLevel
Price

and on the other side we have for instance Products:
ProductId
ProdTitle
Text
BasicPrice
Quantity.

Currently I do it like this:
Have the third party XML convert to classes and XSD’s and then deserialize its contents into strong typed objects (what we get as a result of this process is classes like ThirdPartyProduct, ThirdPartyClassification, etc.).

Then I have methods like this:

InsertProduct(ThirdPartyProduct newproduct)

I do not use interfaces at the moment but I would like to. What I would like is implement something like

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);
        }
    }
}

where ProductSynchronization will be an interface or abstract class. There will most likely be many implementations of ProductSynchronization. I cannot hardcode the types – classes like ContosoProduct, NorthwindProduct might be created from the third party XML’s (so preferably I would continue to use deserialization).

Hopefully someone will understand what I’m trying to explain here. Just imagine you are the seller and you have numerous providers and each one uses their own proprietary XML format. I don’t mind the development, which will of course be needed everytime new format appears, because it will only require 10-20 methods to be implemented, I just want the architecture to be open and support that.

In your replies, please focus on design and not so much on data access technologies because most are pretty straightforward to use (if you need to know, EF will be used for interacting with our database).

Answer 1

[EDIT: Design note]

Ok, from a design perspective I would do xslt on the incoming xml to transform it to a unified format. Also very easy to verify the result xml towards a schema.

Using xslt I would stay away from any interface or abstract class, and just have one class implementation in my code, the internal class. It would keep the code base clean, and the xslt’s themselves should be pretty short if the data is as simple as you state.

Documenting the transformations can easily be done wherever you have your project documentation.

If you decide you absolutely want to have one class per xml (or if you perhaps got a .net dll instead of xml from one customer), then I would make the proxy class inherit an interface or abstract class (based off your internal class, and implement the mappings per property as needed in the proxy classes. This way you can cast any class to your base/internal class.

But seems to me doing the conversion/mapping in code will make the code design a bit more messy.

[Original Answer]

If I understand you correctly you want to map a ThirdPartyProduct class over to your own internal class.

Initially I am thinking class mapping. Use something like Automapper and configure up the mappings as you create your xml deserializing proxy’s. If you make your deserialization end up with the same property names as your internal class, then there’s less config to do for the mapper. Convention over Configuration.

I’d like to hear anyones thoughts on going this route.

Another approach would be to add a .ToInternalProduct( ThirdPartyClass ) in a Converter class. And keep adding more as you add more external classes.

The third approach is for XSLT guys. If you love XSLT you could transform the xml into something which can be deserialized into your internal product class.

Which one of these three I’d choose would depend on the skills of the programmer, and who will maintain adding new external classes. The XSLT approach would require no recompiling or compiling of code as new formats arrived. That might be an advantage.