三层架构

小孩子就喜欢问什么是爱情,可是大人们也不知道 用户界面表示层(UI) 业务逻辑层(BLL) 数据访问层(DAL) 所谓的三层架构,是小白们最流行讨论的话题,以为自己很专业,其实就是很专业,专业到没有人解释得清楚. 那什么是三层呢? 今天你三层了吗? 我见过很多小白,喜欢在代码中写3个项目文件(或者3个文件夹),命名为MODEL, BLL和DAL, DAL里是TSQL与SP, BLL完全只是调用单个DAL方法,例如 CLASS BLL ShowProducts() { DAL.GetProducts(); } 以此类推, 完全是为了三层而三层,并不知道为什么要三层.并不是我给自己儿子起名字叫主席,就可以入主中南海.名字只是个代号. 我不知道这样的BLL是在搞什么. 所谓BLL,它的作用是,,根据用户的某个指令,遵守我们业务所制定的规则,执行流程的作用, 将DAL中所返回的实体进行有机的联系与约束, 然后 或者保存或者展现给用户. 而一个程序,远远不止三层,比如 将结果序列化成json或者xml,(用于ajax或者与webservice通信,或者作为webservice) 依赖注入的IOC容器(用于对象共享与持久化) 即将登上历史舞台的Entity Framework 他们都是抛开业务逻辑,而又不参与TSQL,(Entity Framework是将通用的Entity

１. 三层之间的关系： 三层是指 ：界面显示层(UI)，业务逻辑层(Business)，数据操作层(Data Access) 文字描述 ： Clients对UI进行操作，UI调用Business进行相应的运算和处理，Business通过Data Access对Data Base进行操作。 优点 ： l 增加了代码的重用。Data Access可在多个项目中公用；Business可在同一项目的不同地方使用（如某个软件B/S和C/S部分可以共用一系列的Business组件）。 l 使得软件的分层更加明晰，便于开发和维护。美工人员可以很方便地设计UI设计，并在其中调用Business给出的接口，而程序开发人员则可以专注的进行代码的编写和功能的实现。 ２.Data Access 的具体实现： DataAgent类型中变量和方法的说明： private string m_strConnectionString; //连接字符串 private OleDbConnection m_objConnection; //数据库连接 public DataAgent(string strConnection) //构造方法，传入的参数为连接字符串 private void OpenDataBase() //打开数据库连接 private void #region CloseDataBase() /

原文地址： http://www.work100.net/training/monolithic-architecture-mvc.html 更多教程： 光束云 - 免费课程 MVC架构 序号 文内章节 视频 1 什么是MVC架构 - 2 MVC架构程序的工作流程 - 3 三层架构+MVC示意图 - 请参照如上 章节导航 进行阅读 1.什么是MVC架构 MVC，即 Model 模型、View 视图，及 Controller 控制器。 View ：视图，为用户提供使用界面，与用户直接进行交互。 Model ：模型，承载数据，并对用户提交请求进行计算的模块。其分为两类，一类称为数据承载 Bean，一类称为业务处理 Bean。所谓数据承载 Bean 是指实体类，专门用户承载业务数据的，如 Student 、 User 等。而业务处理 Bean 则是指 Service 或 Dao 对象， 专门用于处理用户提交请求的。 Controller ：控制器，用于将用户请求转发给相应的 Model 进行处理，并根据 Model 的计算结果向用户提供相应响应。 2.MVC架构程序的工作流程 用户通过 View 页面向服务端提出请求，可以是表单请求、超链接请求、AJAX 请求等 服务端 Controller 控制器接收到请求后对请求进行解析，找到相应的 Model 对用户请求进行处理 Model 处理后

MVC模式 MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。 它属于设计模式的范畴，就如同其他设计模式一样，模式的出现就是为了对某种功能的优化，而MVC模式可以看做是对三层架构中表现层的一种细分优化。 MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。 M：Model 模型 主要包括业务逻辑模块（web项目中的Action,dao类）和数据模块（pojo类）。模型 与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性 V：View 视图 用户与之交互的界面、在web中视图一般由jsp,html组成 C：Controller 控制器 接收来自界面的请求 并交给模型进行数据处理后展示到视图，或者直接由视图展示。 在这个过程中控制器不做任何处理只是起到了一个连接的做用 主要功能 模型(JavaBean)：业务逻辑操作，比如封装数据，处理业务数据（调用数据库） 视图(JSP)：展示数据 控制器(Servlet)：获取客户端的输入，调用模型，查询数据获取数据，将数据交给视图展示 优缺点： 优点： 耦合度低

①MVC：---- web开发的设计模式 M：Model—模型 javaBean：封装数据 V：View-----视图 jsp：单纯进行页面的显示 C：Controller----控制器 Servelt：获取数据–对数据进行封装–传递数据-- 指派显示的jsp页面 ②MVC可以说是web层的技术 这个图超级重要 框架代表的功能也都在这张图里 Struts2 SpringMVC 都是web层框架 spring整合web和dao层 也就是service层 hibernate 与mybtis 都是操作dao层的框架 来源： CSDN 作者： 老婆就是要败家 链接： https://blog.csdn.net/qq_45014905/article/details/104338822

MVC三层架构 MVC： Model view Controller 模型、视图、控制器 早些年 用户直接访问控制层，控制层就可以直接操作数据库； servlet--CRUD-->数据库 弊端：程序十分臃肿，不利于维护 servlet的代码中：处理请求、响应、视图跳转、处理JDBC、处理业务代码、处理逻辑代码 架构：没有什么是加一层解决不了的！ 程序猿调用 | JDBC | Mysql Oracle SqlServer ... 如今 MVC三层架构(相当于把controller一部分功能交给Model做) [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZC3k2EFK-1581645507495)(C:\Users\GBZ\AppData\Local\Temp\1581645310065.png)] Model 业务处理 ：业务逻辑（Service） 数据持久层：CRUD （Dao） View 展示数据 提供链接发起Servlet请求 （a，form，img…） Controller （Servlet） 接收用户的请求 ：（req：请求参数、Session信息….） 交给业务层处理对应的代码 控制视图的跳转 登录--->接收用户的登录请求--->处理用户的请求（获取用户登录的参数，username，password）---->交给业务层处理登录业务

　　三层架构主要指java项目设计中的持久层，业务层，和表现层。一般的项目开发都遵循这样的设计思想。 　　持久层：用于完成内存数据和磁盘数据的转换。 　　业务层：完成业务处理，将表现层提供的数据处理完后，交由持久层完成数据的保存。 　　表现层：完成数据的提供和数据的展示，并提供给用户流程控制。 　　主要采用的实现方式如下： 　　持久层主要采用Dao模式，建立实体类和数据库的表之间的映射关系，也就是那个类映射那个表，那个属性映射哪个列，而持久层的目的就是完成对象数据和关系数据的转换。 　　业务层采用业务脚本模式，将一个业务中所有的操作封装成一个方法，保证这个方法的所有数据库更新操作同时成功同时失败，避免出现部分成功部分失败的问题，引起数据混乱的现象。 　　表现层采用了mvc模式：m即模型，也就是使用实体类封装数据并进行传输。v即视图，也就是窗体和GUI，用于数据的提供和数据的展示。c即控制，也就是事件，调用业务方法，以及业务流程的控制。 来源： https://www.cnblogs.com/Freebe/p/6853851.html

三层架构： 1，持久层 2，业务层； 3，表现层 持久层： 完成数据库相关的操作，建立实体类和数据库做映射；采用DAO 模式也就是哪个类对应哪个表，哪个列对应哪个属性，而持久层的目的就是完成对象数据和关系数据的转换； 业务层： 完成处理从表现层中得到的数据和相关的业务操作。采用事物脚本模式将当前业务中所有的操作封装成一个方法，保证这些操作同事成功或同时失败，不允许部分成功或失败，这样避免引起数据混乱的操作； 表现层： 完成数据的收集和展示。采用MVC模式 　　　　　　　　　　　　　　　　M：模型，也就是实体类，用于封装和传输数据 　　　　　　　　　　　　　　　V：视图，也就是GUI窗体，用于数据的展示 　　　　　　　　　　　　　　　　 C：控制，也就是事件，用于控制业务流程 层与层之间用接口做逻辑，（方便替换）做关联，耦合，当其中一个层的组件需要更换不会影响其它层的组件 持久层设计原则:一个实体类一个接口，该接口放置，该实体类中所有的数据库操作，一次数据库操作一个接口方法 接口隔离原则：使用专门的接口，比用统一接口要好，不要让用户面对自用不到的方法，便于分工，便于项目的管理； 业务层设计原则： 一个实体类一个接口，一次提交一个业务方法，业务方法的参数全部来自于表现层； 来源： https://www.cnblogs.com/cj28-27/p/5469849.html

1、持久层 　　完成数据库的相关操作，采用DAO模式，建立实体类和数据库做映射，也就是那个表对应那个类，哪个列对应哪个属性。而持久层的目的就是就是完成对象数据和关系数据的转换。 2、业务层 　　完成处理从表现层中得到的数据，和相关的业务操作。采用事物脚本模式，将当前业务中所有的操作封装成一个方法，保证这些操作同时成功或同时失败，不允许出现部分成功或部分失败，这样引起数据混乱的操作。 3、表现层 　　完成数据的展示和数据的收集，采用MVC模式。 M：模型，也就是实体类，用于封装和传输数据。 V：视图，也就是GUI窗体，用于数据的展示。 C：控制，也就是事件，用于控制业务流程。 　　层于层之间采用接口耦合，这样当其中一个层的组件需要更换不会影响其他层的组件。 　　持久层接口的设计原则：一个实体类一个接口。该接口放置该实体类中所有的数据库操作，一次数据库操作一个接口方法。 来源： https://www.cnblogs.com/jj-0611/p/5453286.html

一、前言 我们先来看看传统的三层架构，如下图所示： 从上图中我们可以看到：在传统的三层架构中，层与层之间是相互依赖的，UI层依赖于BLL层，BLL层依赖于DAL层。分层的目的是为了实现“高内聚、低耦合”。传统的三层架构只有高内聚没有低耦合，层与层之间是一种强依赖的关系，这也是传统三层架构的一种缺点。这种自上而下的依赖关系会导致级联修改，如果低层发生变化，可能上面所有的层都需要去修改，而且这种传统的三层架构也很难实现团队的协同开发，因为上层功能取决于下层功能的实现，下面功能如果没有开发完成，则上层功能也无法进行。 传统的三层架构没有遵循依赖倒置原则（DIP）来设计，所以就会出现上面的问题。 二、依赖倒置 依赖倒置(DIP)：Dependence Inversion Principle的缩写，主要有两层含义： 高层次的模块不应该依赖低层次的模块，两者都应该依赖其抽象。 抽象不应该依赖于具体，具体应该依赖于抽象。 我们先来解释第一句话：高层模块不应该直接依赖低层模块的具体实现，而是应该依赖于低层模块的抽象，也就是说，模块之间的依赖是通过抽象发生的，实现类之间不应该发生直接的依赖关系，他们的依赖关系应该通过接口或者抽象类产生。 在来解释第二句话：接口或者抽象类不应该依赖于实现类。举个例子，假如我们要写BLL层的代码，直接就去实现了功能，等到开发完成以后发现没有使用依赖倒置原则