使用分层实现业务处理（一）

使用Jsp的弊端，页面展示和逻辑掺杂在一起阅读起来不清晰。不利于代码的维护和更新
分层模式可以这样定义，将解决方案的组件分隔到不同的层中，每一层中的组件应保持内聚性，没一层都应于它下面的各层保持松耦合。
三层架构
表示层：最外层，使用户直接能够访问，用于显示数据和接收用户输入的数据，为用户提供一种交互式操作界面
业务逻辑层：业务逻辑层的主要功能就是提供对业务逻辑处理的封装，在业务逻辑层中，通常会定义一些接口，表示层通过调用业务逻辑层的接口来实现各种操作
数据访问层：数据访问层就是实现对数据的保存和读取操作，数据访问，可以访问关系数据库，文本文件或XML文档等
层与层之间的关系
表示层依赖业务逻辑层，业务逻辑依赖于数据访问层各层之间的数据传递方向为请求与响应两个方向
使用三层开发的原则
1.上层依赖下层，依赖关系不跨层
2.下一层不能调用上一层
3.下一层不依赖上一层
4.在上一层不能出现下一层的概念
使用三层开发的优势和特点
1.下层不知道上层的存在
2.每一层仅仅知道它下一层的存在，而不知道另外的下层
使用分层架构的优点如下
1.职责划分清晰
2.无损替换
3.复用代码
4.降低了系统内部的依赖程度
当然在程序中使用分层也有其弊端，原本很直接的操作，现在要通过层层传递，势必造成性能的下降

时间： 2024-10-10 21:38:08

使用分层实现业务处理（一）的相关文章

业务技术协同线上化的硬盘式研发管理实践

摘要: 在云效平台策划推出的<持续集成与交付:阿里最佳实践>专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践. 摘要:在云效平台策划推出的<持续集成与交付:阿里最佳实践>专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践. 以下内容根据演讲

[开源] LaravelPlus - 基于 Laravel 魔改，为方便实际业务使用 - 开发中

目的 为了减少重复 CURD 和新项目的配置麻烦等问题,(就是为了骗星星:LaravelPlus )如: 现有的 infyomlabs/laravel-generator CODE 生成工具虽然好用,但是不太喜欢样式和代码结构. 有些本地,测试,线上的配置需要频繁改动的需要. 多个项目构建引入包,配置扩展等重复性操作 介绍 LaravelPlus 基于 Laravel 增加部分软件包初始安装和进行业务使用功能改动,来创建一个开箱即用的应用 版本基础 当前版本基于 PHP Laravel (影响不

2015前端生态发展回顾

原文:https://github.com/kuitos/kuitos.github.io/issues/32全部文章:https://github.com/kuitos/kuitos.github.io/issues 引用苏宁前端架构师的一个总结作为开篇 编程技术及生态发展的三个阶段 最初的时候人们忙着补全各种API,代表着他们拥有的东西还很匮乏,需要在语言跟基础设施上继续完善 然后就开始各种模式,标志他们做的东西逐渐变大变复杂,需要更好的组织了 然后就是各类分层MVC,MVP,MVVM之类,

Java实战之03Spring-05Spring中的事务控制（基于AOP）

五.Spring中的事务控制(基于AOP) 1.Spring中事务有关的接口 1.1.明确: JavaEE体系进行分层开发,事务处理位于业务层,Spring提供了分层设计业务层的事务处理解决方案 1.2.Spring事务管理主要包括3个接口 1.2.1.PlatformTransactionManager事务管理器 具体实现类: 1.2.2.TransactionDefinition事务定义信息 事务的隔离级别: 事务的传播行为:有时面试会问到 REQUIRED:如果当前没有事务,就新建一个事务

一个小程序能够反映的能力

程序员小郑刚步入岗位,但是在公司编码过程中没有受到专业的编码规范的培训,编写出来的程序虽然能够完成指定的功能但是比较不统一,偶尔会别出心裁的设计出自己的简化方法.老王这是从事了软件编码十多年了,现在都快到不惑的年龄了,在软件行业摸爬滚打十多年从事过多个行业,接触过不同公司的编码的规范,在软件代码编写中有独到的认识. 有一天有一个小功能的改动,由于这是一个非常重要的基础系统的功能变动,所以即便是一个小的功能变动公司上上下下都投入了非常高的重视程度.这天老王找到小郑告诉了需要修改这个系统并详细的描述

Spring之ORM模块

ORM模块对Hibernate.JDO.TopLinkiBatis等ORM框架提供支持 ORM模块依赖于dom4j.jar.antlr.jar等包 在Spring里,Hibernate的资源要交给Spring管理,Hibernate以及其SessionFactory等知识Spring一个特殊的Bean,有Spring负责实例化与销毁.因此DAO层只需要继承HibernateDaoSupport,而不需要与Hibernate的API打交道,不需要开启.关闭Hibernate的Session.Tra

三层架构—简析

三层学习完了,第一次验收的时候,自己理解的也不是很到位,后来又重新敲了一遍登陆例子,查阅了一些资料 进行第二次验收才感觉清晰了许多.之前画时序图时我就想过时序图基本上也是很好的体现了三层,当时也和别人讨 论过这个问题.直到学完三层后,更加证明了这一点. 下面我将从理论和实践两个角度总结一下三层. 理论篇 为什么使用三层架构? 说白了,分层的目的是想将复杂问题简单化,也就是面向对象技术所崇尚的"高内聚,低耦合".当业务复杂到 一定程度,数据存储在独立的存储介质时适合用三层架构. 什么是三

重绘商旅逻辑架构有感

商旅系统一做就是三年,这期间系统由初建到流畅运行,架构上经历了许多次的重构和整理.重新回首,整理一下系统,谈谈自己对逻辑架构的设计实践的一些感想. 商旅系统前后逻辑图如下所示: 这张图是商旅系统最新整理系统逻辑图,与最初相比,有比较多有趣的地方,值得评鉴. 分层架构的清晰. 原有三层的分层架构依旧保留,进行了更进一步的抽象,比如系统管理平台和作业平台细分内容没有进行展示:将应用服务层CC的子系统框架模糊化,定义CC作业平台为渠道端子系统,其服务层和支撑层是子系统内部技术架构,不在总体逻辑架构图展

【优秀博文】知乎服务化的实践与思考

作者:fleuria链接:https://zhuanlan.zhihu.com/p/24044342来源:知乎著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处. 服务化是知乎几年来技术演进故事里的一个主角,公司规模从几十人到几百人,在监控.tracing.框架.容器等基础设施从无到有的同时,也扩展出多个后端技术团队.在服务化演进的过程里,我们也进行了一些新的思考. 服务化的愿景 「微服务」 是业内最近两三年业内很火的 buzzword,迁移到微服务架构,大多强调这些好处: 松耦