12.3.2 MongoDB 持久化实体映射
Spring Data MongoDB 提供了一组注解，用于将实体类映射到 MongoDB 的文档结构上。这组 Spring Data MongoDB 注解有好几个，其中有三个是最常用的：
@Id—— 将属性指定为文档的 Id（在 Spring Data Commons 中）@Document—— 声明实体类型要持久化为 MongoDB 文档@Field—— 指定持久化文档中存储这个属性的字段名称（以及可选的顺序）
在这三个注释中，只有
@Id 和 @Document 注解是必须有的。除非另行指定，否则没有使用 @Field 注解的属性，将假定字段名等于属性名。为 Ingredient 类添加这些注解后，可以得到以下结果：
package tacos;
import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.mapping.Document;
import lombok.AccessLevel;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.RequiredArgsConstructor;
@Data
@RequiredArgsConstructor
@NoArgsConstructor(access=AccessLevel.PRIVATE, force=true)
@Document
public class Ingredient {
@Id
private final String id;
private final String name;
private final Type type;
public static enum Type {
WRAP, PROTEIN, VEGGIES, CHEESE, SAUCE
}
}
如您所见，您将
@Document 注解放置在类级别上，以指示 Ingredient 是一个文档实体，可以写入 Mongo 数据库并从中读取。默认情况下，Collection 名称（Mongo 中类似于关系数据库的 Table）基于类名，第一个字母小写。因为你没有进行指定，Ingredient 对象将持久化到名为 ingredient 的 Collection 中。但是您可以通过设置 @Document 的 collection 属性来改变这一点：@Data
@RequiredArgsConstructor
@NoArgsConstructor(access=AccessLevel.PRIVATE, force=true)
@Document(collection="ingredients")
public class Ingredient {
...
}
您还注意到 id 属性已经添加了
@id 注解，这指定了此属性作为持久化文档的 ID 。您可以在任何属性上使用 @Id 注解，只要其类型是可序列化的，这包括 String 和 Long。在现在这种情况下，您的 id 属性是 String 类型，所以没有必要将其更改为其他类型。到目前为止，进展还不错。您可能还记得在本章前面的内容中，为 Cassandra 添加映射时，Ingredient 类是容易处理的实体类型。其他类型，如 Taco，更复杂一些。让我们看看现在如何映射 Taco 类。
与前面一样，您肯定需要为 Taco 类添加
@Document 注解。您还需要用 @Id 指定一个 ID 属性。这样做以后的 Taco 类如下：@Data
@RestResource(rel="tacos", path="tacos")
@Document
public class Taco {
@Id
private String id;
@NotNull
@Size(min=5, message="Name must be at least 5 characters long")
private String name;
private Date createdAt = new Date();
@Size(min=1, message="You must choose at least 1 ingredient")
private List<Ingredient> ingredients;
}
信不信由你，这样就可以了！处理两个不同主键，以及用户自定义类型，只是特定于 Cassandra 的。对于 MongoDB 来说，Taco 类的映射要简单得多。
即便如此，在 Taco 中还是有一些有趣的事情需要指出来。首先，注意 id 属性已更改为 String（而不是 JPA 版本中的 Long，或者 Cassandra 版的 UUID）。正如我之前所说，
@Id 可以应用于任何可序列化的类型。但是如果您选择使用 String 属性作为 ID，那么 Mongo 会在保存时自动为其赋值（如果它是空的）。通过选择 String，您可以获得一个由数据库管理的自动分配的 ID，而不必费心手动设置该属性。另外，注意 ingredients 属性，这是一个列表，就像第三章的 JPA 版本一样。但与 JPA 版本不同的是：不是存储在单独的 MongoDB 集合中。就像 Cassandra 时那样，taco 表直接存储在 taco 文档中，这是非规范化的。但是与 Cassandra 的实现不同，您不需要构建用户自定义的类型，在这里 MongoDB 允许使用任何类型。不管它是另一个添加了
@Document 注解的类型或只是一个 POJO。看到将 Taco 映射为文档结构进行 Mongo 持久性很容易，这无疑是一种解脱。这种映射的简单性会延续到 Order 类吗？您自己看看添加了 MongoDB 注解的 Order 类吧：
@Data
@Document
public class Order implements Serializable {
private static final long serialVersionUID = 1L;
@Id
private String id;
private Date placedAt = new Date();
@Field("customer")
private User user;
// other properties omitted for brevity's sake
private List<Taco> tacos = new ArrayList<>();
public void addDesign(Taco design) {
this.tacos.add(design);
}
}
为了简洁起见，我删掉了 delivery 和 credit card 字段。但是从剩下的属性来看，很明显，您只需要
@Document 和 @Id 注解，就像其他实体类型那样。即便如此，您还是要为 user 属性加上 @Field 注解，以指定在持久化文档中，使用 customer 字段来进行存储。从到目前为止的经验可以得知，映射 MongoDB 的 User 类应该同样容易：
@Data
@NoArgsConstructor(access=AccessLevel.PRIVATE, force=true)
@RequiredArgsConstructor
@Document
public class User implements UserDetails {
private static final long serialVersionUID = 1L;
@Id
private String id;
private final String username;
private final String password;
private final String fullname;
private final String street;
private final String city;
private final String state;
private final String zip;
private final String phoneNumber;
// UserDetails method omitted for brevity's sake
}
尽管有一些更高级和不寻常的情况，需要额外的映射配置。但在大多数情况下，
@Document 和 @Id 以及偶尔使用 @Field，对于 MongoDB 的映射就足够了。这三个注解就完全满足了 Taco Cloud 应用的类型映射工作。剩下的就是编写 Repository 接口了。