2

当我们有一个固定的数据库设计并且我们需要支持从第三方数据源(很可能是 XML)导入数据时,您将如何在 .NET 中设计应用程序(类、类库中的接口)?

例如,假设我们的数据库中有一个 Products 表,其中包含 Id Title Description TaxLevel Price 列

另一方面,我们有例如 Products: ProductId ProdTitle Text BasicPrice Quantity。

目前我这样做是这样的:让第三方 XML 转换为类和 XSD,然后将其内容反序列化为强类型对象(此过程的结果是类,如 ThirdPartyProduct、ThirdPartyClassification 等)。

然后我有这样的方法:

InsertProduct(ThirdPartyProduct newproduct)

我目前不使用接口,但我想。我想要的是实现类似

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

其中 ProductSynchronization 将是一个接口或抽象类。ProductSynchronization 很可能会有很多实现。我无法对这些类型进行硬编码 - ContosoProduct、NorthwindProduct 等类可能是从第三方 XML 创建的(所以我最好继续使用反序列化)。

希望有人能理解我在这里试图解释的内容。试想一下,您是卖方,您有许多供应商,而且每个供应商都使用自己专有的 XML 格式。我不介意开发,当然每次出现新格式时都需要开发,因为它只需要实现 10-20 个方法,我只希望架构是开放的并支持它。

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).

4

1 回答 1

0

[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.

于 2010-06-10T19:07:08.410 回答