我正在构建一个依赖于另一个服务的服务。典型的面向服务的架构。我所依赖的服务公开了一些 API 和数据类型。我很困惑是否应该将该服务公开的对象类型转换为我的服务可以理解的特定对象。我确实希望他们的服务会随着时间而改变，因为这是两种不同的服务。我有两个选择:
- 直接在我的服务中使用这些数据类型并在方法中传递这些数据类型。
- 将它们转换为只有我的服务可以理解的特定数据类型。 (如果我进行 0 次更改，对象看起来将完全相同)。
我试图回答这些问题，但仍然无法做出最终决定。我需要帮助来做出这个决定。
为什么我应该封装/转换类型？
- 防止每次在服务中进行构建更改时进行构建。
- 为了防止广泛的更改(适配器模式):更改电线 格式将导致我只更改封装类。
为什么我不应该更改封装的类型？
- 这些类看起来与有线格式类完全相同。 (维持额外类(class)的努力是无用的)
据我了解，无论我采用哪种方法，影响都会相同。帮忙？
最佳答案
我不是架构师或 SOA 专家，所以如果我说了什么愚蠢的话请原谅:-)
但我确实认为这里的方法是让您的服务保持简单。
站在你的立场上，我会直接使用现有的 API。我不会花任何时间将这些方法包装或改编到另一个 API 中。您的第二个服务(使用现有的第一个服务)业务逻辑应该处理此转换，IMO，除非您被迫使用现有 API 做一些非常昂贵的事情。。 p>
请记住，服务是可变的。它们是软件。它们存在错误，业务逻辑随着时间的推移而变化，您必须更改 API，有时您必须保持旧方法与其他服务使用者兼容。如果没有任何充分的实际原因，您可能不想维护两个提供相同信息的 API。不需要两倍的维护工作。
创建另一个 API 只是为了适应数据格式，对我来说听起来有点像古老的“DTO 是邪恶的”激烈 war 。我认为现在很少有人写过使用 DTO 的优点:-)
关于java - 将对象从一种格式转换为另一种 Java(设计模式)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23099968/