我为一家拥有多个网站的公司工作,而现有的基础设施......很好,很糟糕。
现在,每个商店都有自己的表格,结构各异。这很快成为一个问题(如果还没有)。
因此,我需要找到一种方法从多个渠道接受订单,将它们格式化为单一,统一的方式,将它们存储在最后,并将它们转换回商店API所期望的格式(可以是RESTful JSON to SOAP)。
我最初的直觉反应是工厂,访客和构建器模式的混合(加上一些聪明的多态性),但它太复杂得太快了。在我使用可能不是最佳,可维护或可扩展的解决方案编写自己的角落之前,是否存在更高效的模式或模式集?
基本上,我认为它会是这样的:
Source -> Translator -> Our Format
Our Format -> Translator -> Source
我不需要翻译人员真正对数据采取行动。所有它应该负责的是以正确的格式获得它,我们可以从A点到B点(反之亦然)。
关于该系统的一些假设:
答案 0 :(得分:1)
Adapter Pattern是你的朋友。我们假设您有一个遗留的客户类。
public class CustomerLegacy
{
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime Birthday { get; set; }
}
您可能想要做的第一件事就是提取该类。此步骤是可选的,但它使新类可测试。因此,您将拥有如下所示的ICustomerLegacy界面。
public interface ICustomerLegacy
{
string FirstName { get; set; }
string LastName { get; set; }
DateTime Birthday { get; set; }
}
然后重构CustomerLegacy
类来实现新接口。
public class CustomerLegacy
: ICustomerLegacy
下一步是创建一个以ICustomerLegacy
作为构造函数参数的适配器。您可以添加新属性以满足您的需求。
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();
}
}
正如您所看到的,Adapter Pattern可以帮助您重构现有产品,使其可测试,并在一个地方整理遗留代码。
答案 1 :(得分:0)
据我所知,您应该能够使用一种简单的方法来处理这种情况,包括工厂和界面,
HttpWebResponse
这里Order对象应该转换为实际实现中的特定API,并且反过来用于任何获取数据的方法。
然后可以使用工厂根据常量或基于枚举创建相关商店。
答案 2 :(得分:0)
在我以前的一家公司中,我们从事过类似的项目。我们采用Pipe and filters架构。
使用管道和过滤器架构样式将较大的处理任务划分为一系列通过通道(管道)连接的较小的独立处理步骤(过滤器)。
每个过滤器都公开一个非常简单的接口:它在入站管道上接收消息,处理消息,并将结果发布到出站管道。管道将一个过滤器连接到下一个过滤器,从一个过滤器向下一个过滤器发送输出消息。由于所有组件都使用相同的外部接口,因此可以通过将组件连接到不同的管道将它们组合成不同的解决方我们可以添加新过滤器,省略现有过滤器或将它们重新排列成新序列 - 所有这些都无需更改过滤器本身。过滤器和管道之间的连接有时称为端口。在基本形式中,每个过滤器组件都有一个输入端口和一个输出端口。
将其视为您的Source
是Pump,您的Translator
是过滤器。放入过滤器的任何功能都将从相应的业务域驱动。大局看起来像这样: