我目前正在开发一个项目，我正在添加一个新的休息界面。 我写了一个通用的转换器，它将响应转换成一些对象。 现在，我问自己是否应该转换这些对象，让我们将它们称为rest-interface对象，成为一组新的对象，这将是我的模型。大多数时候，数据都是一样的 但有时候我会有不同的数据表示。例如。其余的响应会有一个日期作为时间戳，但我的模型对象会有一个日期对象。
如果我决定将其余界面更改为例如，那么另一件好事就是肥皂 我的客户端代码只依赖于模型对象，因此我只需要 照顾转换。一个缺点是如果我必须在两个地方改变一些东西。
我不确定这个主题的最佳做法是什么。我还有一个将rest-interface对象转换为模型对象的过度杀伤（发送请求和响应的方式）。很高兴听到一些关于这个的想法，也许有人知道一些解释这个问题的资源。
答案 0 :(得分：1)
有没有听说过“过早优化”？通常，在设计应用程序时，我不会过于关注性能。确保您创建可读代码，易于维护，将来易于扩展以及通常的未来证明（例如，从REST切换到SOAP不应该造成比必要更麻烦;这可能比您在时刻）。你不应该选择糟糕的设计，只是因为你“认为”它可能有更好的性能，或者因为你认为“好的设计”可能会有糟糕的表现。
老实说，您计划在一秒内完成多少次REST调用以及在单个REST结果中有多少个对象？你可以创建最好的设计，如果你以后出现现场性能瓶颈（浪费太多CPU时间，浪费太多内存等），那么你就开始优化这些瓶颈了。如果幸运的话，开始时就不会有瓶颈。如果您主要关注的是创建地球所见过的最快的代码片段，那么您将不会使用Java开始，您可能会使用最低级别的C，使用内联汇编，无论您必须挤出最后一个CPU性能下降。
所以我不会在REST API之后对我的设计进行建模，我会按照我认为的方式对我的设计进行建模，最简单的方法是对应用程序的其余部分进行编码，然后编写一个转换器的导入器/导出器REST到我的设计，我的设计到REST。如果你转而使用其他技术，比如SOAP，我只需重写导入器/导出器，而不是整个应用程序。
但也有例外：我个人不喜欢任何OO语言的日期对象。时间戳是完美的日期表示IMHO，它很容易使用（比较，添加/减去偏移等）并且它具有非常低的内存开销（只是数字，通常是原始的，甚至不是内存分配必要）。因此，除非您需要日期对象，否则您无法按需要存储或显示此值，否则我会将时间戳保留为时间戳，如果您将来切换到SOAP并且它提供日期而不是时间戳，我宁愿将它们转换为时间戳在进口商和回到出口商的日期。然而，这只是我。