11 | 实战一（上）：业务开发常用的基于贫血模型的MVC架构违背OOP吗？

小时候妈妈说我贫血 ，长大了才知道我真的贫血

看到「领域驱动设计有点儿类似敏捷开发、SOA、PAAS 等概念，听起来很高大上，但实际上只值“五分钱”。」时，不知道引起了多少人的共鸣，O(∩_∩)O~。 做技术的本身就经常会遇到沟通问题，一些人还总喜欢“造概念”，唯恐别人听懂了，争哥这句话无疑说中了我们的心坎儿。 当然我这里也不是说 DDD 不好（看后面的争哥也没这个意思），但是每个理论都有自己的局限性和适用性，看很多文章在讲一些理论时，总是恨不得把自己的理论（其实也算不得自己的）吹成银弹，态度上就让人很难接受。 我还是喜欢争哥的风格，逻辑很清晰，也很严谨，很务实。 关于老师的问题。 说句实话，我们就没有写过充血模型的代码。 我们会把 UserEntity、UserBo 混着用， UserBo 和 UserVo 之间转换时有时还会用 BeanUtils 之类的工具 copy 。 对于复杂的逻辑，我们就用复杂 SQL 或者 Service 中的代码解决。 不过我在翻一些框架时，比如 Java 的并发包时不可避免的需要梳理 Lock、Condition、Synchronizer 之间的关系。比如看 Spring IOC 时，也会需要梳理围绕着 Context 、 Factory 展开的很多类之间的关系。 就好像你要“混某个圈子”时，就不可避免的“拜码头”，认识一堆“七大姑八大姨”，然后你才能理解整个“圈子”里的关系和运转逻辑。 我也经常会有疑问， DDD 和面向对象究竟是什么关系，也会猜想：是不是面向对象主要关注“圈子”内的问题，而 DDD 主要关注“圈子”之间的问题？有没有高手可以回答一下。 （其实我最近一直都想订隔壁DDD的课，但是考虑到精力的问题，以及担心学不会，主要不是争哥讲O(∩_∩)O~，所以没下手）

能否用代码表达一下充血模型，其实还是不太理解

1.目前基本都在接触贫血开发模型，充血的可能局部模块设计的时候，会把数据和方法组织到一个类里面去。但是DB的操作完全隔离。 这里有一个问题:充血模型的话，OOP的想法，应该是每个人(假设人是类，具体的人就是人这个类的实例化)管理自己的属性，比如我的主管。 这个时候有一个需求。批量修改人员的主管。那么充血模型是要遍历委托给每个具体的人自己去修改呢？还是提供一个service，直接批量操作DB。 2. entity,bo,vo我的做法是不合并，但是真的有贯穿三层的模型。那么就直接用一个。但是要单独分包。并且组内规范好这个包里面的东西都是有修改风险的。我个人倾向用麻烦换容错。毕竟软件的变化性比较大

1. 以前做的项目都是基于贫血模型的，这次的话涉及风控业务，也是基于贫血模型，但是各种问题不断，正在考虑优化，这里刚好看到老师的文章，希望能有所借鉴。 2. Entity是ORM中数据库映射的实体类，BO是业务操作相关实体类，VO是视图层对应实体类。在简单情况下，这三个类可能是一样的，比方说你填写一个登陆注册的表单，此时前端传给后端接口的数据，一般就是VO，而通过业务层Service操作，加入创建时间，IP地址等，就转换成了BO，最后对应到数据层就转换为了Entity，也许一次注册可能需要写多个库，就会生成多个Entity。 有些复杂业务，还有DO,DTO，PO之类的概念，但是个人感觉很模糊，也不是很了解。这里希望老师能指点一下。

项目中用到了google的ProtocolBuffer，根据数据结构体生成的类模型只能包含数据，不能包含方法。这种情况也是贫血模型吧。

要是有代码例子就好了。实操性会强很多。

最近在看消息队列的专栏，里面有提到Pulsar这个产品采用了存储与计算分离的设计。本质上和文中提到的数据与操作分离应该是一个意思吧？难道也是一种面向过程的设计

看完了, 感觉热血沸腾, 特别期待下一节课. 课堂讨论: 1, 自己所参与做的项目中都是典型的基于贫血模型开发模式. 2, 我是基本都用一个类的, 因为所做的系统业务想比较简单, 也就没必要, 还有些共用的属性字段会拿出来,用继承的方式. 基本项目都是这么过来的. 也没遇到啥问题, (大家勿笑哈) 从第一节课听到现在, 受益匪浅, 每节课都会听个3-5遍. 到现在, 基本能意识到自己在工作种存在的一些问题,以及需要提升进步的地方, 期待后面的课程....

MVC是面向过程编程，是因为它违反了封装的特性，数据和逻辑操作分离开了，在controller进行相关数据逻辑操作，而model仅仅只是个数据层，没有任何操作。而MVVM是面向对象编程，因为它把数据和其相关逻辑操作封装在了viewModel，只暴露给外部相关方法，controller想要获取数据直接通过这些方法就行了，不用像MVC在controller层进行一堆逻辑操作，同时减轻了controller的代码，在viewModel也方便维护数据逻辑操作。不知道这样的理解对不对？