将下订单操作写入DAO存在那些漏洞？

下单操作的时候会存在一些问题，比如说重复提交的问题，以及逻辑处理的时候，存在多个表更新、插入的问题，这个时候最好使用事务来处理，比如中间出错，进行回滚的操作

下订单操作写入DAO会引起很多问题，比如你在下单时候的业务逻辑交互会出错乱，造成其他DAO的混乱，引起异常报错等。

SpringMVC服务端采用经典的三层架构，即表现层、业务层、持久层，分别采用@Controller、@Service、@Repository进行类注解，比如Controller层负责接收客户端请求，并返回处理结果 Service层负责业务逻辑处理，根据不同功能划分 Persistence持久层负责数据的持久化到数据库，比如

而对于下单操作，当然属于业务逻辑的操作，在SpringMVC服务端的三层结构中属于Service业务逻辑层，写在Service层的话不但符合三层架构的规范，也使代码的可读性可维护性大大提高。

如果写在DAO层，也就是Persistence持久层，那么后期维护时除了要关注Service存在的业务逻辑处理外还要关注Persistence持久层是否也存在业务逻辑，可读性、可维护性大大降低，很容易造成遗漏BUG，或者其他数据问题；另外，通常情况下，下单会伴随着增减库存，增减积分等操作，而Spring事务的注解需要加在Service层来保证整体所有业务逻辑操作的一致性，如果业务逻辑写在DAO层，也就是Persistence持久层的话，数据的一致性就无法保证了，可能还有其他问题，这里暂时没想到

从MVC架构设计角度来说，DAO层负责模型层主要处理数据操作，Service层负责业务逻辑处理，Controller是视图层负责view。每层各司其职，降低业务逻辑的依赖，“高内聚，低耦合”说的就是这个意思。

下订单应该是业务层逻辑，里面会有很多逻辑交互，比如说“插入订单、检查库存、更新库存、新增物流信息等”，每个处理都是一个DAO，然后在Service层完成业务组装；如果我们把下订单的业务逻辑放在DAO会导致代码逻辑不清晰、扩展性不强、容易导致不必要BUG

在俩个不同的DAO对象中均可对book进行操作

在俩个不同的DAO对象中均可对book进行操作