我目前正在开发一个项目，其中要添加一个新的休息界面。 我编写了一个通用转换器，它将响应转换为一些对象。 现在我问自己是否应该将这些对象转换为休息接口(interface)对象，并将其转换为一组新的对象，这将是我的模型。大多数时候，数据是相同的 但有时我会对数据有不同的表示。例如。其余响应将有一个日期作为时间戳，但我的模型对象将有一个日期对象。
另一件好事是，如果我决定将其余界面更改为例如肥皂 我的客户端代码仅依赖于模型对象，因此我只需要 处理转换。一个缺点是，如果我必须更改某些内容，我需要在两个地方进行。
我不确定这个主题的最佳实践是什么。我还将其余接口(interface)对象转换为模型对象(发送请求和响应的两种方式)。很高兴听到对此的一些想法，也许有人知道一些可以很好解释这一点的资源。
最佳答案
听说过“过早优化”吗？一般来说，在设计应用程序时我不会太关心性能。确保您创建可读的代码，易于维护，易于将来扩展，并且通常不会过时(例如，从 REST 切换到 SOAP 不应造成不必要的麻烦；这可能是比您想象的更现实的场景)片刻)。您不应该仅仅因为您“认为”它可能具有更好的性能或者因为您认为“好的设计”可能具有较差的性能而选择糟糕的设计。
老实说，您计划每秒进行多少次 REST 调用以及单个 REST 结果中有多少百万个对象？您可以创建最好的设计，如果您稍后发现性能瓶颈(浪费了太多的 CPU 时间、浪费了太多的内存等)，那么您就开始优化这些瓶颈。如果幸运的话，一开始就不会有瓶颈。如果您主要关心的是创建地球上有史以来最快的代码段，那么您一开始就不会使用 Java，您可能会使用尽可能最低级别的 C，并在必须挤出最后一个代码的地方使用内联汇编。 CPU 性能下降。
所以我不会在 REST API 之后对我的设计进行建模，我会按照我认为应该的方式对我的设计进行建模，最简单地对应用程序的其余部分进行编码，然后编写一个可以转换的导入器/导出器休息到我的设计，我的设计休息。如果您随后切换到另一种技术，例如 SOAP，我只需重写导入器/导出器，而不是整个应用程序。
不过也有异常(exception):我个人不喜欢任何面向对象语言中的日期对象。恕我直言，时间戳是一个完美的日期表示，它非常容易使用(比较、添加/减去偏移量等)，并且它的内存开销非常低(只是数字，通常是基元，甚至不需要内存分配)必要的)。因此，除非您需要日期对象，否则您无法根据需要存储或显示该值，否则我会保留时间戳作为时间戳，如果您将来切换到 SOAP 并且它提供日期而不是时间戳，我宁愿将它们转换为时间戳在进口商中并返回到导出商中的日期。但这只是我。
关于java - Model对象的抽象合理吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14221998/