MVC分层架构是怎么样的
这篇文章给大家分享的是有关MVC分层架构是怎么样的的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
创新互联公司成立十多年来,这条路我们正越走越好,积累了技术与客户资源,形成了良好的口碑。为客户提供做网站、成都做网站、网站策划、网页设计、国际域名空间、网络营销、VI设计、网站改版、漏洞修补等服务。网站是否美观、功能强大、用户体验好、性价比高、打开快等等,这些对于网站建设都非常重要,创新互联公司通过对建站技术性的掌握、对创意设计的研究为客户提供一站式互联网解决方案,携手广大客户,共同发展进步。
传统MVC三层架构
通常,我们习惯的业务建模方式是围绕数据表的,先根据业务需要设计数据库,再完成业务流程的开发。
在实现层面采用MVC分层框架,业务数据在3个层级之间流动(数据的流动性本质)。
虽然采用了MVC分层设计,但是在业务流程实现上仍旧是面向过程式,通常遵循这样的开发模式:取数据 -> 处理数据 -> 存储数据,是一种以数据为中心的过程式思想。
大家可以思考一下,你是不是也是这样开发业务的?
领域驱动设计(DDD)
该理论提出了一种新的分层模式,核心是强调面向对象。
interfaces是表现层,仍旧负责数据渲染,比如渲染页面,渲染json等等。
domain是领域层,是指具体的某一类实体与操作的类封装,比如订单与订单相关的操作。
application是应用层,组装多个domain,组成一个具体的业务流程,比如交易下单流程,可能需要调用订单、用户、反作弊等等domain。
对于订单来说,我们传统MVC通常只把它当做数据库记录,是一个”贫血模型”,里面只有订单的各个属性列,通过调用model层从数据库获取。同时,我们会写一个service层,封装对订单记录的业务操作方法,即过程式的面向数据的开发模式。
而DDD则不同,它强调订单是一类实体,具体某一条订单则对应一个订单对象。订单对象具有自己的业务处理方法,数据和方法是封装在一起的。
此时,如果创建订单需要获取用户信息,那么就需要application层来做组装:先获取用户对象,再调用订单对象的方法传入用户对象来完成下单的一个流程。
application就是来做具体业务流程的一层,进行多个domain的组装。
MVC与DDD的结合
没有银弹,多参考不同的思想,目标是如何优化业务设计与定制高效的开发规范。
我感觉DDD本质就是让属于不同领域的功能内聚,然后在应用层组装不同领域的功能即可。
而反观我们面向数据的思考方式,很容易做出这样的事情:为了实现一个跨领域的业务流程,直接将多种不同领域的业务逻辑实现在一起,即把分属于不同领域的逻辑一股脑的丢在应用逻辑层实现,导致了设计越来越混乱,复用性越来越低。
其实我们也不必完全参考DDD直接改造成面向对象的领域设计,毕竟团队擅长的建模方式仍旧是围绕数据的,而不是围绕领域对象的。
我们完全可以借助DDD来优化MVC分层设计,也就是以领域的眼光来优化MVC的使用。
之前在百度的时候,公司推广PHP Yaf框架的开发规范就提到很重要的一点,即遵循如下的分层设计:
view
controller
page
service
model
结合DDD,我们来重新设计一下每一层要做的事情:
model:特定领域数据的数据读写,比如 订单领域:
一般来说,订单分为主表和扩展表,两张表完整表达了订单业务,所以我会把它俩作为一个model实现。
service:该层与model层一一对应,说白了将model视作领域的数据部分(纯数据),service视作领域的方法部分,共同组成了类似DDD中的实体,只不过我们仍旧是面向数据和过程的实现。
page:与DDD的application层对应,组装多个service构成业务流程,向controller返回结果。
controller:解析请求,组装参数,调用page完成业务流程,将page返回值进一步加工成view需要的具体样子。
view:直接渲染html或者Json等,不应该包含其他的数据处理逻辑。
总结我的想法,service+model应该配对出现,page组装多个service完成业务流程,controller只是page与view之间的协调者(不应该有任何业务逻辑),
另外,service+model应该按领域思想划分,而不是按数据表划分,这样可以解决大多数的联表需求。
对于事务需求,应该在application层控制事务开关,依旧组装多个service完成事务内操作,保证不同领域的边界清晰。
感谢各位的阅读!关于“MVC分层架构是怎么样的”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
当前文章:MVC分层架构是怎么样的
网站路径:http://ybzwz.com/article/giepgh.html