Oop 用于将多个数据源中的多种数据格式转换为单一格式的设计模式

我在一家拥有多个网站的公司工作，而现有的基础设施……嗯，糟糕透了

现在，每个商店都有自己的表，表的结构各不相同。这正迅速成为一个问题（如果还没有的话）

因此，我需要找到一种方法，从多个渠道接收订单，将它们格式化为一种统一的方式，在我们的终端存储它们，并将它们转换回StoreAPI所期望的格式（可以是从RESTful JSON到SOAP的所有内容）

我最初的直觉反应是工厂、访客和建筑商模式的混合（再加上一些智能多态性），但它变得有点太复杂太快了。在我用可能不是最优的、可维护的或可扩展的解决方案将自己编码到一个角落之前，是否有一种模式或一组模式更有效

基本上，我认为应该是这样的：

Source -> Translator -> Our Format
Our Format -> Translator -> Source

我不需要译者对数据进行实际操作。它所应该负责的就是以正确的格式获取它，我们可以从A点到B点获取它（反之亦然）

关于系统的一些假设：

我们这边的格式不太可能改变，因此我们的对象也不太可能改变

当数据被转换回原始源时，我们可以假设所需的一切都将在那里。外边界请求的实际行为是小的、集中的和定义良好的

他是你的朋友。假设您有一个遗留客户类

public class CustomerLegacy
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    public DateTime Birthday { get; set; }
}

您可能要做的第一件事是提取该类的。此步骤是可选的，但它使新类可测试。因此，您将拥有如下所示的ICCustomerLegacy接口

public interface ICustomerLegacy
{
    string FirstName { get; set; }

    string LastName { get; set; }

    DateTime Birthday { get; set; }
}

然后重构

CustomerLegacy

类以实现新接口

public class CustomerLegacy
    : ICustomerLegacy

下一步是创建一个将

icCustomerLegacy

作为构造函数参数的适配器。您可以添加新属性以满足您的需要

public class CustomerAdapter
{
    private readonly ICustomerLegacy customer;

    public CustomerAdapter(ICustomerLegacy customer)
    {
        this.customer = customer;
    }

    public string FullName
    {
        get
        {
            return this.customer.FirstName + " " + this.customer.LastName;
        }
    }

    public int Age
    {
        get
        {
            return DateTime.UtcNow.Year - this.customer.Birthday.Year;
        }
        set
        {
            // your logic here.
        }
    }

    public void Save()
    {
        //this.customer.DoSomething();
    }
}

---

正如您所见，适配器模式可以帮助您重构现有产品，使其可测试，并在一个地方整理遗留代码。

据我所知，您应该能够使用一种简单的方法来处理这种情况，使用工厂和接口

class IStore
{
   void Place(Order order);

   ....other methods
}

class AmazonStore : IStore
{
   ...implement methods
}

class EbayStore : IStore
{
    ...implement methods
}

在这里，Order对象应该被转换为实际实现中的特定API，对于任何获取数据的方法，也应该被转换为特定API

---

然后，可以使用工厂根据常量或枚举创建相关存储。

在我以前的一家公司，我们曾从事过类似的项目。我们采用这种架构

使用“管道和过滤器”体系结构样式将较大的处理任务划分为一系列由通道（管道）连接的较小、独立的处理步骤（过滤器）

每个筛选器都公开了一个非常简单的接口：它在入站管道上接收消息，处理消息，并将结果发布到出站管道。管道将一个过滤器连接到下一个过滤器，将输出消息从一个过滤器发送到下一个过滤器。因为所有组件都使用相同的外部接口，所以通过将组件连接到不同的管道，可以将它们组合成不同的解决方案。我们可以添加新的过滤器，省略现有的过滤器，或者将它们重新排列成新的序列——所有这些都不需要更改过滤器本身。过滤器和管道之间的连接有时称为端口。在基本形式中，每个过滤器组件都有一个输入端口和一个输出端口

把它想象成你的

源代码

是泵，你的

翻译器

是过滤器。过滤器中的任何功能都将从相应的业务域驱动。大局是这样的：