** 1 . 服务用法：当你看到一个hibernate spring教程时，他们都说对于一个实体（例如我的用户）你必须有一个名为UserRepository的存储库，其中包含find，findAll，delete等方法 . 通常，UserRepository扩展了一些基础知识库接口 .
然后你必须添加UserService，它注入一个UserRepository .
a . 我必须有一个UserService接口由UserServiceImpl实现吗？从我的角度来看，它没有增加任何 Value . 我可以让UserService成为一个类，并使用Spring的能力使用GCLIB而不是JDKInterfaces创建代理 .
b . 通过从UserRepository复制每个方法并委托给@Autowired存储库，然后添加任何其他业务方法来编写UserService是否正确？
c . 如果我的UserService没有任何业务方法，它只是将所有内容委托给UserRepository，我可以跳过UserService并直接从我的REST层访问UserRepoisitory吗？
d . 让's say that I also have an Address entity. The user needs an Address when saving ( it is a one2one mandatory ). Is it ok from UserService to inject both UserRepository and AddressRepository inside of it, set up relations there and then call save on each repository? ( don' t想要使用级联持久化，我想知道如果没有它我怎么办，因为在某些情况下你不能使用级联）
2. DTO用法：当您想要读取数据时，您可以通过JPQL（或Criteria，我更喜欢JPQL）直接获取实体或获取DTO .
a . 从我的角度来看，我总是使用DTO而不是实体获取 . 这是因为，我认为SQL很简单，如果我不得不考虑实体合并，分离，附加等，我会错过SQL的简单性，ORM在性能和复杂性方面成为敌人 . 因此，当我修改数据时，我总是在读取数据和实体时使用DTO . 你怎么看？
b . 我想从User实体返回所有列 . 是否可以使用UserDTo或我夸大其词并且应该返回用户实体？我50％ - 50％ .
c . 我想从User返回部分列 . 在这里，我是75％DTO和25％实体 . 你怎么看？
d . 我想返回一些User列和一些Address列 . 在这里，我100％为DTO（虽然我可以加入获取地址） . 你怎么看？
亲切的问候，
1 回答
我将逐一回答：
1.a）是的，它确实有意义 . 服务层是事务边界，它是通过课程粒度接口将业务逻辑公开给外部世界的地方 .
1.b）不，不是 . UserService定义业务方法，而不是数据访问方法 .
1.c）我仍然保留服务 .
1.d）当然是 . 您无需通过实体名称调用服务 . 根据他们表达的业务逻辑关注来命名 .
2.a）我的规则很简单：计划修改时的实体和只读预测的DTO .
2.b）与2.a相同
2.c）与2.a相同If you need to modify the fetched data later, then use subentities .
2.d）与2.a相同如果需要修改数据，请使用实体或子实体 . 否则，DTO用于只读投影 .