今个聊一聊传统IT的集中式三层架构和主流开发技术选型
5墨值下载
Theme:
聊一聊传统
IT
的集中式三层架构和主流开发技术选型
摘要：
最近在看一本书《未来架构
从服务化到云原生》，关于技术架构这部分，结合书中内容，有一些认知和
感悟。
互联网的技术架构正在经历由集中式—
分布式—
云平台的发展历程中。这三种技术架构是一个迭代发展
过程，技术和优势也是一个逐渐演进过程；从业务需求和架构成熟度来说，是一个愈加递增、健壮的发展。
目前，集中式架构主要集中在传统
行业，分布式和云平台技术架构集中在需求演变快速的互联网行业；
但这并不能表明满足低并发、扩展性差的集中式架构就落后了，对于传统行业来说，在业务压力不大的、
并发要求和扩展性不高、公司技术人员能力迭代更新延迟的前提下，集中式三层架构依旧有其优势和价值。
今天就来聊一聊集中式三层架构模型。
很多同学可能都知道传统的三层模型：
层、服务层、数据访问层。这里再行赘述下：
数据访问层用于定义数据访问接口，实现对真实数据库的访问服务；
服务层用于对应用业务逻辑处理；
层用于处理异常、逻辑跳转控制、页面渲染模型等，又被称为
层（
）。
在传统三层架构中，
还未兴起，故数据访问层主要对关系型数据进行访问。
开发中，访问关系型数据库需要通过统一接口层
，通过
可以很方便的访问各种关系型数据
库（
、
、
!
、
"#"#
）。
然而存储在关系数据库中的二位关系表格面向集合设计的数据与面向对象的模型思维并不容易映射、对应。
于是有了很多
#
（
$%#&'()%))*
）框架，目的是为了使用面向对象的理念去操控数据库。
其中
&'
（前身是
）、
+
及其默认实现
,
，是
#
框架领域的开源产品；其中
+
是
官方的持久化设计规范，但在实际使用中略显笨重，故业界采用更为灵活、可控性更高的
&'
作
为
#
框架首选。
服务层实现业务应用的逻辑处理，承接数据层和
层，故需要一个能便捷访问数据层和
层的框架。
官方推荐
"!-.
，但因其大量的
.
配置和繁琐的部署方式，不为开发者中意；即使后续推出的简化
很多的
"/-.
，依旧没能成为
开发标准。
业界大神
#('
开发了
)*01
（很多同学看到这个词估计都笑了，很熟悉对不对），极大
简化了
""
开发，提供了
（控制反转）和
+
（面向切面编程）特性，因给开发者带来极大开发便
捷性，迅速被接受为
后端实际开发标准。
)*01
提供一种容器能力，容器中任何对象都以
方式注入，能够很优雅便捷的串联、整合
数据访问对象和其他第三方组。
再讲一下
Web
层，又被称为
mvc
层（
Model View Controller
）。
用于分离前端展现和后端服务，最初有
的
标准实现，但因为
侵入了大量的
,2)#34'
、
,2)#')'
、
,2)''
等
+
，导致基于
'
的开发程序并不适用于单元测试，这就
很大阻碍了整体研发进度的推进，大大增加了研发周期和成本；且实现配置、跳转、表单封装等操作存在
大量重复工作。
因此需要更好的
框架来改善开发流程，
4'5-.
及基于
1
封装的
4'!-.6)*
，初期
因
4'
使用简单收到开发者喜爱，后
)*
对
开发力度增大，且由于设计理念清晰和与
)*
,
强融合能力，成为
框架业界主流标准。
由以上，故当今实现 集中式三层架构的主流技术 选型 为：
)*0174'
（
)*
）
7
+8,9
开发
''(
套件；或
)*0174'
（
)*
）
7
（
&'
）开发
''(
套件。
总结：
5-
本文简述了集中式三层架构，并给出了个人观点：对于传统行业来说，在业务压力不大的、并发要求和
扩展性不高、公司技术人员能力迭代更新延迟的前提下，集中式三层架构依旧有其优势和价值；
!-
当今实现集中式三层架构的主流技术选型为：
)*0174'
（
)*
）
7+8,9
开发
''(
套件；或
)*0174'
（
)*
）
7
（
&'
）开发
''(
套件。
/-
还是那句话：适合自己才是最好的；既要仰望星空，也要脚踏实地。
of 2
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论