我创建了一个具有几乎相同的数据架构的应用程序。我们有一个现场SQL数据库,其中包含大多数自动化和内部日常信息,然后还有一个用于销售,客户管理,现场人员等的第三方云服务。帮助台需要这两个有关客户实际位置的信息和设备,并且一直是从两个不同的应用程序获得的,直到我介入。
总而言之,一个数据源需要引用另一个数据源的记录。在我们的案例中,第三方云数据包含对现场数据的引用,因为这是我们最能控制的安排。现在,有了来自任何一个数据源的记录的ID,我们就可以从两个数据源中获取数据。使用云ID,我们从云中提取记录,获取现场ID,然后提取现场数据。使用现场ID,我们根据该ID轮询两个数据源。
在我的系统中,我没有在域层中使任何一个对象成为另一个对象的子对象。来自两个存储的数据的任何使用都必须维护两个对象实例。没有人保证存在,这就是为什么我这样做了。该应用程序只能使用云数据或现场数据,或同时使用这两种数据,但限制越多,其数据越少。
但是,这并不难改变,尤其是在您确定一侧将始终存在的情况下。只需在对象中包含一个属性,该属性表示将始终存在数据的那一侧,即对象类型的属性表示另一个数据存储的记录。可以将两个图形更高级地“合并”为一个。
这种安排必须在某种程度上耦合。您可以拥有一个既可以与两个数据存储接口的DAL,也可以对每个数据存储的DAL进行分段,并具有更高的层,例如Controller从每个数据存储中获取数据并将它们对齐。但是,在某种程度上,您的程序必须具有将这两个不同数据源的数据放在一起的技巧。
您可以通过抽象出数据确切来源的详细信息来减少大多数情况下所需的耦合。如果您从Web服务获取数据(将其作为生成的类的实例提供给您),则放置一个转换器以将服务类的深层副本复制到您控制的内容中,如果数据源(仅在架构存在的情况下)。
现在,这可能是一项艰巨的任务。我们使用的云具有数十个域类,其中一些具有数百个数据字段,而且,这很重要,您可以非常轻松地对抽象数据类型进行大的更改,以适应迁移到其他云或其他远程站点数据源。因此,我没有打扰。我直接使用生成的Web服务域,现在从云到异地(但在我们的控制之下)数据存储的变化迫在眉睫,我仍然不知道其详细信息,我只是打算更改表单和应用程序的代码隐藏(在此处数据被“组合”),以反映新的架构和/或数据对象。无论您采用哪种方式切片,这都是一项艰巨的工作。