命令查询职责分离模式(Command Query Responsibility Segregation,CQRS)
CQRS只是简单的将之前只需要创建一个对象拆分成了两个对象,这种分离是基于方法是【执行命令】还是【执行查询】这一原则来定的
CURD缺点:
1.使用同一个对象实体来进行数据库读写可能会太粗糙,大多数情况下,比如编辑的时候可能只需要更新个别字段,但是却需要将整个对象都穿进去,有些字段其实是不需要更新的。在查询的时候在表现层可能只需要个别字段,但是需要查询和返回整个实体对象。
2.使用同一实体对象对同一数据进行读写操作的时候,可能会遇到资源竞争的情况,经常要处理的锁的问题,在写入数据的时候,需要加锁。读取数据的时候需要判断是否允许脏读。这样使得系统的逻辑性和复杂性增加,并且会对系统吞吐量的增长会产生影响。
3.同步,直接与数据库进行交互在大数据量同时访问的情况下可能会影响性能和响应性,并且可能会产生性能瓶颈。
4.由于同一实体对象都会在读写操作中用到,所以对于安全和权限的管理会变得比较复杂。
CQRS:
将操作的查询和纯查询分离
纯查询:eg.前端的find,不会修改数据的查询动作
操作的查询:eg.删除一个id=3的数据,将需要操作的数据查询出的动作
配合主从分离数据库:
主数据库处理CUD
从库处理R 从库因为只涉及查询 可以是用视图或者与主库结构不一样,因为不需要操作,只是单纯的查询
CQRS优点:
分工明确,可以负责不同的部分
将业务上的命令和查询的职责分离能够提高系统的性能、可扩展性和安全性。并且在系统的演化中能够保持高度的灵活性,能够防止出现CRUD模式中,对查询或者修改中的某一方进行改动,导致另一方出现问题的情况。
逻辑清晰,能够看到系统中的那些行为或者操作导致了系统的状态变化。
【可以从数据驱动转到任务驱动以及事件驱动】
CQRS缺点:
分工不明确,造成较高的沟通成本
领域模型比较简单,简单的情况下是用CQRS会导致项目过于复杂,设计过度
网友评论