如何表示对象并在不同源/位置之间进行映射
我将构建一个系统,其中特定对象将源自 Web 服务(基于 SOAP)。然后它将显示在网页上(通过 PHP)。在某些情况下,我们会在本地 MySQL 数据库中存储包含一些附加信息的副本。然后,它将被批处理到 Salesforce CRM(同样通过 PHP)。随后,我们还可能从 Salesforce 中提取该对象以在线显示。发生了很多事情。大多数情况下,该对象与系统中的每个后续节点相同,可能会添加几个特定于它的字段,主要是唯一的 ID。
我最初考虑过将所有必要的功能封装到 PHP 中的一个类中,该类将处理从每个适当的源进行读取和写入的操作。这感觉让课程变得过于复杂,而不是一个好方法。
然后我考虑只有一个容器类,除了 getter 和 setter 之外没有附加任何实际功能。然后在此之外创建单独的功能来处理不同源之间的读写,代码足够简单,尽管在不同源的所有不同字段名称之间进行映射很繁琐。可能有一两个设计模式适用于此,但我对它们并不熟悉。任何关于如何解决这个问题的建议都值得赞赏。
I will be building a system where a particular object will originate from a web service (SOAP based). It will then be displayed on a web page (via PHP). Under certain circumstances we'll store a copy with some additional information in a local MySQL database. And from there it will be batch processed into Salesforce CRM (again via PHP). We may also subsequently pull the object out of Salesforce for display online. So alot going on. For the most part the object is the same with each subsequent node in the system likely adding a couple of fields specific to it, unique ids mainly.
I'd initially toyed with the idea of encapsulating all the necessary functionality into the one class in PHP which would deal with reading and writing from each of the appropriate sources. This felt like it was over complicating the class, and not a good approach.
I then looked at having just a container class, with no real functionality attached beyond getters and setters. Then creating separate functionality outside of this to deal with the reading and writing between the different sources, simple enough code although tedious to map between all the different field names across the different sources. There is probably a design pattern or two that apply here, but I'm not familiar with them. Any and all suggestions on how to approach this appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(10)
您正在寻找的是 Adapter 模式。您可以保留现有代码,直到完全更改所有类。
What you are looking is Adapter pattern. You can keep your existing code till you completely change all the classes.
我建议使用 composite 备忘录 可序列化为 XML。
I'd suggest to use a composite memento serializable into XML.
我认为他们可能有几种方法来处理这个问题。 @EGL 2-101 适配器的想法是一种方法。
基本上,您有多个源,用面向对象的术语来说,它们是不同的对象。但是,您希望将它们视为单个对象。
您可能想为每个源创建一个类,测试“连接”,就好像每种情况都是您要使用的唯一方法一样。当您有多个此类时,请尝试使所有类共享一些接口、方法或属性:
稍后,使用单个类来包装所有这些源类。
稍后,添加代码,以选择您想要的“连接”。
I think they may be several ways to handle that. @EGL 2-101 adapter idea is one way to do it.
Basically, you have several sources, which in O.O. jargon, are different objects. But, you want to treated like if they where a single object.
You may want to make a single class for each source, test the "connection", as if each case was the only way you where going to work with. When you have several of that classes, try to make all classes share some interface, methods or properties:
Later, use a single class to wrap to all of these source classes.
Later, add the code, to select which "connection" you want.
为什么不把数据和操作分开呢?
将核心信息包含到类
C
中。当 Web 服务发送此类时,它包含在某个类W
的对象中。 Web 服务拉取C
并将其发送到持久层,持久层创建并存储内部包含C
等的P
,类似于数据如何在 TCP/IP 堆栈上流动......
Why not separate data and operations?
Contain the core information into a class
C
. When web services sends this class, it is encompassed in an object of some classW
. The web service pullsC
and sends it to persistence layer, which creates and storesP
that internally containsC
, et.c.,Akin to how data flows over a TCP/IP stack...
经过一番思考后,我认为这几乎是一个处理对象然后序列化它的类。
我可能会使用这样的东西:
然后用它来将序列化的数据传递给不同的网络服务。
我认为 JSON 在这方面会做得非常好,因为您可以在许多编程语言中轻松快速地反序列化它,而且它比 XML 轻得多。
The way I see this after thinking about it a bit would be pretty much a class to play with your object and then serialize it.
I'd probably use something like this:
Then just use it to pass it serialized to your different web services.
I think JSON would do a pretty good job on this one, because you can easily unserialize it fast in so many programming languages and it's so much lighter than XML.
DataMapper 模式就是您正在寻找的。
您可以为您使用的每种存储机制拥有一个映射器,并将它们全部与一个代表业务逻辑数据的对象一起使用。
DataMapper pattern is that what you're looking for.
You can have one mapper for each storage mechanism that you use and use them all with one object that represent data to business logic.
看来您的问题更多的是架构/设计决策,而不是纯粹的实现细节。 (我已经很长时间没有使用 PHP 了,不了解 salesforce,但了解其他 CRM 系统)
我相信对您有用的技术/模式是使用暂存区。如果您有不断变化的集成需求,并且当您的源数据看起来与系统模型不同或当您有不同的源可供集成时,这尤其有帮助。因此,您可以导入到暂存区域,然后从暂存区域导入到系统中。在每个地方,您自然必须映射(可以使用元数据)并且可能转换/翻译数据。构建此系统将需要付出初步努力,但一旦完成,从暂存到系统的步骤将保持相当静态/稳定。
使用元数据映射可以解决灵活性问题,但会增加实现的复杂性。这完全取决于您手头的项目技能和时间。
Is seems your problem is more of an architectural / design decision that pure implementation detail. (I haven't done PHP for a long while and do not know salesforce but other CRM systems)
I believe the technique/pattern that will work for you is the use of a staging area. This helps especially if you have changing integration needs and also when your source data looks different from your system model or when you have different sources to integrate from. Thus, you import into the staging area and then from the staging into your system. At each place you naturally have to map (can use metadata) and maybe transform/translate data. There will be initial effort to build this, but once it's done the step from staging to your system stays quite static/stable.
Using meta data mapping can address flexibility concerns but adds a bit of complexity on implementation. It all depends on the skills and time you have at hand for your project.
我根本不会在对象之间建立任何关联。它们用于不同的目的,但看起来相似。时期。
在 .NET 中,我们使用一个名为
automapper
的库在不同类(如业务对象和 DTO)之间复制信息。您可以使用 get_object_vars 或 反射 API。I would not have any association between the objects at all. They are used for different purposes but looks similar. period.
In .NET we use a library called
automapper
to copy information between different classes (like a business object and a DTO). You can build something similar in PHP, either by using get_object_vars or the reflection API.假设您从网络服务检索一辆汽车。您可以将其存储在 WebserviceCar 中,该 WebserviceCar 具有属性汽车。
现在,如果您想将该汽车存储在数据库中,请将其放入 DatabaseCar 中,该数据库也有一个属性 car。如果您想将其放入 Salesforce 中,请将其放入 SalesforceCar 对象中,该对象有一个属性汽车。
这样,您就拥有一个具有公共字段的对象和多个具有存储特定信息的对象。
Say you retrieve a Car from the webservice. You can store it in a WebserviceCar, which has a property car.
Now, if you want to store that Car in the database, put it in a DatabaseCar, which also has a property car. If you want to put it in Salesforce, put it in a SalesforceCar object, which has a property car.
This way, you have one object which has the common fields and several objects which have storage-specific information.
假设您正在考虑将实际对象(序列化、编码或其他)存储在数据库的字段中:从我的角度来看,对象在两个应用程序中永远不会相同,从业务角度来看,它服务于不同的目的。这样做是在没有“短切”余地的情况下的一种“短切”。
请记住,类主要代表“对象类别”,它们都共享相同的属性和行为。因此,让每个应用程序根据其目的需要使用它自己的类。不过,正如其他人所建议的和您所想的那样,可以创建的是创建适配器或工厂,它可以在所有隐含的应用程序中使用,因为它服务于对象的相同业务目的“翻译”。
适配器模式
工厂模式
Assuming that you are thinking about storing the actual object (serialized,encoded or whatever) in a field in the database: From my point of view the object it is never the same in two applications, as business-wise, it serves different purposes. Doing this is a kind of "cutting short" in a case where is no room for "cutting short".
Remember that mainly class represents a "category of objects" which all share same properties and behaviours. So let each application use it's own class as their purpose requires it. What can be created although is, as others suggested and as you thought, the creation of an Adapter or Factory which can be used in all the implied applications as it serves the same business purposes "translation" of objects.
Adapter pattern
Factory pattern