我有一个对象设计问题。
我正在用Java构建json api。我的系统使用pojos表示json对象，并使用Jackson将其从json转换为pojo。每个对象在不同的上下文中需要采用不同的形式，我无法决定是否创建一堆单独的类，为每个上下文创建一个类，还是尝试在所有情况下都使一个通用的类工作。
让我举一个具体的例子。
系统有用户。该api具有添加，修改和删除用途的服务。数据库中有一个用户表。数据库记录如下所示：
{
id: 123, // autoincrement
name: "Bob",
passwordHash: "random string",
unmodifiable: "some string"
}
当您发布/添加用户时，您的pojo不应包含ID，因为它是自动生成的。您还希望能够包含一个密码，该密码会被散列并存储在数据库中。
当您放置/更新用户时，您的pojo不应包含不可修改的字段，但必须包含ID，以便您知道要修改的用户。
当获取/检索用户时，您应该获得除passwordHash之外的所有字段。
因此，代表用户的pojo具有不同的属性，具体取决于您是要添加，更新还是检索用户。并且它在数据库中具有不同的属性。
那么，我应该在系统中创建四个不同的pojo并在其中进行转换吗？还是创建一个User类并尝试使用Jackson视图或其他某种机制使其在不同情况下看起来有所不同？
我发现后一种方法真的很难管理。
最佳答案
我认为您应该仅创建一个具有所有必需属性的POJO-User。现在，您应该确定您的API是严格还是宽大。如果您的API严格，则在收到错误的JSON数据时应返回错误。在宽松版本中，API可以跳过多余的（不必要的）属性。
在提供示例之前，让我将“ passwordHash”属性更改为“ password”。
添加新用户/ POST
来自客户的JSON数据：
{
id: 123,
name: "Bob",
password: "random string",
unmodifiable: "some string"
}
严格的版本可以返回例如以下内容：
{
"status": "ERROR",
"errors": [
{
"errorType": 1001,
"message": "Id field is not allowed in POST request."
}
]
}
宽松版本可以返回例如以下内容：
{
"status": "SUCCESS",
"warnings": [
"Id field was omitted."
]
}
对于每个
CRUD方法，您可以编写一组单元测试，这些单元测试将保存选择哪种方式以及允许和不允许的信息。