【发布时间】：2017-08-01 09:21:31
【问题描述】：
我们有“bean”，旨在序列化为 JSON，然后返回到我们（基于 vue.js）的 UI 层。到目前为止，我的 bean 看起来像这样：
public class ExampleBean {
private final int id;
private final String name;
public ExampleBean(int id, String name) {
this.id = id; ...
}
// getter for all fields
}
它们由一些映射器实例化：
public ExampleBean map(SomeInternalThing foo) {
int id = getIdFromFoo(foo);
String name = doSomethingElse(foo.itsBar());
return new ExampleBean(id, name);
}
然后我有一些单元测试（用于映射器）：
@Test
public void testGetId() {
... do some mocking setup so that the mapper can do its job
assertThat(mapperUnderTest.map(someFoo).getId(), is(5));
}
这种方法的主要优点是 bean 对象是不可变的（当我忘记初始化字段时编译器会告诉我）。
但是：该 bean 的字段数量不断增加。 SomeInternalThing 上下文可能有 30 到 50 个“属性”，并且 bean 中所需的字段数......现在从 3 到 5 到 8。
真正“扼杀”我的是 映射 代码为每个必填字段做不同的事情。这需要我处理越来越多的“通用”模拟规范。
现在我想知道是否有更好的 选择来实现这种“仅数据对象”。
【问题讨论】：
-
我喜欢MapStruct，我用它来将 JPA 实体映射到 DTO 或从 DTO 映射。我们在视图层中使用 DTO。使用 MapStruct，您可以自动生成映射器，并在必要时使用注释进行自定义。但是，不确定它与不可变 DTO 的工作情况如何。
-
如何转移映射器方法的逻辑并使用真正的转储映射器逻辑？在我看来，这将导致更简单的映射器测试和更简单的逻辑测试。
-
您必须映射许多类，其中包含许多具有不同名称的字段。映射器不是真正的问题。你需要它们，因为模型就是这样设计的。否则你应该重做所有模型类。但有可能吗？对于实际模型，我认为模拟映射任务似乎很昂贵，太昂贵了。也许您应该测试映射器与使用它的实际类的集成。它会使 mapper 被多次测试，但如果它使你的测试类变得难以阅读且难以维护，那么隔离它们的价值是什么？
标签： java data-structures javabeans