什么是三层架构？

1. 什么是三层架构？

2. 三层架构是什么？

MVC是三个单词的缩写,分别为： 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。 View层用于与用户的交互，通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。

目录

MVC与模板概念的理解
MVC如何工作视图
模型
控制器
为什么要使用 MVC
MVC的优点低耦合性
高重用性和可适用性
较低的生命周期成本
快速的部署
可维护性
有利于软件工程化管理
MVC的缺点
开发方式Java开发Web Application
.NET开发Web Application
php 开发Web Application
常见的MVC组件
Struts 中Model 1 和Model 2简介Model 1
Model 2
Struts的结构和处理流程简介
利用Struts框架开发
 MVC与模板概念的理解
　　MVC(Model View Controller)模型－视图－控制器 　　MVC本来是存在于Deskt
op程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVCcopyright: Apple Inc.
的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。 　　模型－视图－控制器（MVC）是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Oracle旗下Sun公司Java EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。
MVC如何工作
　　MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。
视图
　　视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services. 　　如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
模型
　　模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器
　　控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。
为什么要使用 MVC
　　大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化(自PHP5.0版本后已全面支持面向对象模型)语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是毋庸置疑的。 　　首先，最重要的一点是多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。 　　由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Adobe Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。 　　因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松耦合的构件。 　　对我来说，控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
MVC的优点
低耦合性
　　视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
高重用性和可适用性
　　随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC模式允许你使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无需做任何改变。
较低的生命周期成本
　　MVC使降低开发和维护用户接口的技术含量成为可能。
快速的部署
　　使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
可维护性
　　分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
有利于软件工程化管理
　　由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。
MVC的缺点
　　MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。 　　你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。 　　根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。 　　MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。 　　MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。
开发方式
Java开发Web Application
　　Java开发Web Application有几种符合MVC设计模式的开发方式。 　　1:Jsp+Servlet+JavaBean(EJB) 　　2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model) 　　3:TDK(Turbine，Velocity...) 　　4:Xsp 　　5:Jsp+Struts+JavaBean(EJB) 　　6:SSH (Struts + Spring + Hibernate)
.NET开发Web Application
　　.NET开发Web Application可以采用： 　　1:ASP.NET MVC Framework（ASP.NET MVC ） 　　2:MonoRail (RC3) 　　3:ASP.NET MVC2
php 开发Web Application
　　php 开发Web Application 可以采用： 　　1. Zend framework PHP官方框架 　　2. fleaphp/Qeephp 等国内流行框架 　　3. CakePHP 等国外流行框架 　　4. ThinkPHP 等其他框架
常见的MVC组件
　　Struts： Apache的，最流行的MVC组件 　　Struts2 ：Apache用Struts 和 WebWork的组合出来的新产品，目前上升势头强劲 　　WebWork： 这个可是老牌的MVC组件，后来组合成了Struts2, 不过自身仍在发展 　　Spring MVC：SpringFramework自己整合自己Spring的优势推出的MVC组件，用户也不少 　　JSF： 这个是一个规范，Sun的和 Apache的都有各自的实现。用户量很大，被众多IDE支持。 　　Tapestry： 最彻底的MVC开发框架，丰富的组件资源，重用性很高。组件扮演着控制器Controller的角色，是模式层（Model） 中pure-domain objects和包含有组件的HTML模板之间的媒介。大多数情况下，这种方式应用于页面（页面也 是 Tapestry组件），但是在某些情况中，一个组件拥有自己的模板，包含着更多的组件，并且支持与使用者的互交。页面通过配置一系列属性表达式（Property expressions）连接模式层和表现层。属性表达式使用另外一种开源框架OGNL（Object Graph Navigation Language）。OGNL的开源工程（project）独立于Tapestry，但是在Tapestry中起很重要的作用。OGNL主要的目的在于读取和更新对象的Java Bean属性。 　　.net mvc：在.net上的mvc组件，经过了preview1~5，RC1，RC2，目前已经是正式版了，微软给出的定义是可以用于生产的架构。配合VS2008以及将要出现的VS2010，相信.net mvc将会是MVC家族的重要的一员。
Struts 中Model 1 和Model 2简介
　　我们在开发Web应用时经常提到的一个概念是Model1/Model2，那么到底它是什么意思呢？其实它是对采用JSP技术构成Web应用的不同模型的描述。下面对这个概念做一个简单的介绍。
Model 1
　　在使用JAVA技术建立Web应用的实例中，由于JSP技术的发展，很快这种便于掌握和可实现快速开发的技术就成了创建Web应用的主要技术。JSP页面中可以非常容易地结合业务逻辑（jsp:useBean）、服务端处理过程（jsp:let）和HTML（），在JSP页面中同时实现显示，业务逻辑和流程控制，从而可以快速地完成应用开发。现在很多的Web应用就是由一组JSP页面构成的。这种以JSP为中心的开发模型我们可以称之为Model1。 　　当然这种开发模式在进行快速和小规模的应用开发时，是有非常大的优势，但是从工程化的角度考虑，它也有一些不足之处： 　　应用的实现一般是基于过程的，一组JSP页面实现一个业务流程，如果要进行改动，必须在多个地方进行修改。这样非常不利于应用扩展和更新。 　　由于应用不是建立在模块上的，业务逻辑和表示逻辑混合在JSP页面中没有进行抽象和分离。所以非常不利于应用系统业务的重用和改动。 　　考虑到这些问题在开发大型的Web应用时必须采用不同的设计模式――这就是Model2
Model 2
　　Model 2表示的是基于MVC模式的框架。MVC是Model－View－Controller的简写。“Model”代表的是应用的业务逻辑（通过JavaBean，EJB组件实现），“View”是应用的表示面（由JSP页面产生），“Controller”是提供应用的处理过程控制（一般是一个Servlet），通过这种设计模型把应用逻辑，处理过程和显示逻辑分成不同的组件实现。这些组件可以进行交互和重用。从而弥补了Model1的不足。 　　Model2具有组件化的优点从而更易于实现对大规模系统的开发和管理，但是开发StrutsMVC系统比简单的JSP开发要复杂许多，它需要更多的时间学习和掌握。同时新东西的引入会带来新的问题（这让我想起来关于“自动计算”的一篇文章，中间提到为了降低系统的复杂度，却导致更高的复杂度）。 　　必须基于StrutsMVC组件的方式重新思考和设计应用结构。原来通过建立一个简单的JSP页面就能实现的应用现在变成了多个步骤的设计和实现过程。 　　所有的页面和组件必须在Struts MVC框架中实现，所以必须进行附加地开发工作。 　　StrutsMVC本身就是一个非常复杂的系统，所以采用StrutsMVC实现Web应用时，最好选一个现成的MVC框架，在此之下进行开发，从而取得事半功倍的效果。现在有很多可供使用的MVC框架，由于Struts有完整的文档并且相对来讲比较简单，所以用它开发MVC系统还是比较方便地。
Struts的结构和处理流程简介
　　Struts1是Apache组织的一个项目，像其他的Apache组织的项目一样，它也是开放源码项目。Struts1是一个比较好的MVC框架提供了对开发MVC系统的底层支持，它采用的主要技术是Servlet，JSP和customtaglibrary。 　　作为一个MVC的框架，Struts1对Model、View和Controller都提供了对应的实现组件，分别进行介绍，并且看看它们是如何结合在一起的。 　　Controller：控制器的作用是从客户端接受请求，并且选择执行相应的业务逻辑，然后把响应结果送回到客户端。在Struts1中Controller功能由图中ActionServlet和ActionMapping对象构成：核心是一个Servlet类型的对象ActionServlet，它用来接受客户端的请求。ActionServlet包括一组基于配置的ActionMapping对象，每个ActionMapping对象实现了一个请求到一个具体的Model部分中Action处理器对象之间的映射。 　　Model：StrutsMVC系统中的Model部分从概念上可以分为两类――系统的内部状态，和改变系统状态的动作。Struts1为Model部分提供了Action和ActionForm对象：所有的Action处理器对象都是开发者从Struts1的Action类派生的子类。Action处理器对象封装了具体的处理逻辑，调用业务逻辑模块，并且把响应提交到合适的View组件以产生响应。Struts1提供的ActionForm组件对象，它可以通过定义属性描述客户端表单数据。开发者可以从它派生子类对象，利用它和Struts提供的自定义标记库结合可以实现对客户端的表单数据的良好封装和支持，Action处理器对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过ActionForm组件对象实现了对View和Model之间交互的支持。Struts1通常建议使用一组JavaBean表示系统的内部状态，根据系统的复杂度也可以使用像EntityEJB和SessionEJB等组件来实现系统状态。Struts建议在实现时把“做什么”（Action）和“如何做”（业务逻辑）分离。这样可以实现业务逻辑的重用。 　　View：Struts1应用中的View部分是通过JSP技术实现的。Struts1提供了自定义的标签库(tag library)可以使用，通过这些自定义标签(tag)可以非常好地和系统的Model部分交互，通过使用这些自定义标签创建的JSP表单，可以实现和Model部分中的ActionForm的映射，完成对用户数据的封装，同时这些自定义标签还提供了像模板定制等多种显示功能。 　　StrutsMVC框架的处理流程清楚的体现了MVC系统的特点，简单的Struts组件结构。StrutsControllerActionServlet处理客户请求，利用配置的ActionMapping对象把请求映射到Action处理器对象进行处理。Action处理对象访问ActionForm中的数据，处理和响应客户请求，它还调用后台的Bean组件，这些组件封装了具体的业务逻辑。Action处理器对象根据处理结果通知Controller，Controller进行下一步的处理。
利用Struts框架开发
　　Struts1 MVC系统要做的工作 　　由于Struts已经为我们提供了一个非常好的MVC框架，我们利用Struts开发MVC系统时可以大大加快开发的速度。在开发时可以采用的一个开发流程如下（引自资料3）： 　　收集和定义应用需求。 　　基于数据采集和显示的原则定义和开发“屏幕显示”需求 。 　　为每一个“屏幕显示”定义访问路径。 　　定义ActionMappings建立到应用业务逻辑之间的联系。 　　开发满足“屏幕显示”需求的所有支持对象。 　　基于每一个“屏幕显示”需求提供的数据属性来创建对应的ActionForm对象 　　开发被ActionMapping调用的Action对象。 　　开发应用业务逻辑对象 （Bean，EJB，等等）。 　　对应ActionMapping设计的流程创建JSP页面。 　　建立合适的配置文件struts-config.xml ， web.xml。 　　开发/测试/部署 　　具体在使用Struts框架时，对应各个部分的开发工作主要包括： 　　Model部分：采用JavaBean和EJB组件，设计和实现系统的业务逻辑。根据不同的请求从Action派生具体Action处理对象。完成“做什么”的任务来调用由Bean构成的业务组件。创建由ActionForm的派生类实现对客户端表单数据的封装。 　　Controller部分：Struts为我们提供了核心控制部分的实现。我们只需要配置ActionMapping对象 　　View部分：为了使用Model中的ActionForm对象，我们必须用Struts提供的自定义标记创建HTML表单。利用Struts提供的自定义标记库编写用户界面把应用逻辑和显示逻辑分离。Struts框架通过这些自定义标记建立了View和Model之间的联系。Struts的自定义标记还提供了很多定制页面的功能。 　　同时需要编辑两个配置文件：web.xml和struts-config.xml。通过它们配置Struts系统中的各个模块之间的交互。下面对这两个配置文件做一些介绍： 　　web.xml文件的配置： 　　web应用中的web.xml是第一个要配置的地方，它描述了系统的Controller对象。在web.xml中增加如下标记 　　action 　　org.apache.struts.action.ActionServlet 　　application  　　说明：这个servlet对象就是Struts提供的Controller，还可以为它指定初始化参数，比如对系统应用属性的支持。 　　 action*.do 　　说明：实现客户请求的url信息和服务器端具体处理的映射关系。 　　/WEB-INF/struts-bean.tld 　　/WEB-INF/struts-bean.tld 　　说明：添加对Struts提供的应用所使用的自定义标记库的引用。 　　struts-config.xml文件的配置： 　　struts-config.xml是用于建立Controller和Model之间的关系的。它描述了Controller所使用的把请求对应到具体处理的法则，同时它还描述了客户提供的数据与ActionForm组件的对应映射关系。 　　在struts-config.xml中增加如下标记 　　  　　说明：标记描述一个具体的ActionForm子类对象，通过它和JSP页面中的自定标记的结合使用可以实现ActionForm和View之间的数据映射。 　　 　　说明：标记描述了请求和处理的一对一映射关系。input和path属性唯一的标记了客户端的一个请求，name属性描述封装客户端的数据的ActionForm子类对象。Type属性描述处理这个请求的Action子类对象。 　　[1]通过对两个配置文件的配置，把Struts MVC框架中MVC的各个部分联系起来，实现一个真正的Struts MVC系统。

3. 三层架构是什么？

通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候的所见所得。业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等每层之间是一种垂直的关系。三层结构是N层结构的一种，一般来说，层次之间是向下依赖的，下层代码未确定其接口（契约）前，上层代码是无法开发的，下层代码接口（契约）的变化将使上层的代码一起变化。
优点： 分工明确，条理清晰，易于调试，而且具有可扩展性。
缺点： 增加成本。

4. 三层架构各层之间的依赖关系是什么？

三层架构分别为表现层、业务逻辑层、数据访问层。
三层架构各层之间的依赖关系是：
1、表现层依赖业务逻辑层以实现业务数据处理。
2、业务逻辑层依赖数据访问层来读取数据库中的数据或将处理结果存入数据库中。
3、而数据访问层与表现层的依赖刚好相反。
其实使用三层架构开发的重点在业务逻辑层的实现。
三层架构区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。

扩展资料
三层架构每层的作用：
1、数据访问层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。
2、业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
3、界面层：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。
参考资料：百度百科-三层架构

5. 三层结构中数据访问层的主要功能是什么

从业务规则层接收请求，从数据服务获取数据或向其发送数据。 使用存储过程获取数据，并可选用 ADO.NET 向数据库发送数据，将数据库查询结果返回到业务规则层，作为ADO.NET 数据集。 
数据数据访问层主要看数据层里面有没有包含逻辑处理，实际上各个函数主要完成各个对数据文件的操作。而不必管其他操作。业务逻辑层主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。

扩展资料：
注意事项：
借鉴多种分布式数据库访问模式，基于MySQL开源协议，采用数据库代理方式，形成分布式数据库中间件解决方案，解决分布式系统数据库分库分表带来的数据透明访问难题。
在负载均衡的控制方面，通过LVS+zookeeper实现负载均衡、可设置权重实现灰度发布，通过keepalived+VIP消除单点故障隐患。
参考资料来源：百度百科-数据访问层

6. 三层架构各层之间的依赖关系是什么？

 三层架构各层之间的依赖关系是什么？, 什么是三层架构？各层的主要功能及相互关系有哪些  一般讲到三层架构，其实就是将整个业务应用划分为表示层、业务逻辑层、数据访问层等。  数据访问层DAL，业务逻辑层BLL。表现层UI （界面类的）【 model（数据模型层，主要放的我就不用说了。一般都是数据库中的。） ，】model是贯穿的。所有的都引用它，bll引用dal ui引用dal 和bll 然后就是调用  三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。  普通三层：数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。 业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。 表示层UI：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。业务实体Model：用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增强灵活性。 通用类库Common：通用的辅助工具类  工程模式：简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。  工厂角色（Creator）  是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。  抽象产品角色（Product）  是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。  具体产品角色（Concrete Product）  继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。  通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通 讯与中间层建立连接，再经由中间层与数据库进行交换.  完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层 否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说. 不同的应用有不同的理解，这是一个概念的问题．  MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。  MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。 同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。 在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。  在ASP NET中的MVC架构编写的，具有极其良好的可扩展性。它可以轻松实现以下功能： ①实现一个模型的多个视图；②采用多个控制器；③当模型改变时，所有视图将自动刷新；④所有的控制器将相互独立工作。这就是MVC架构的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC架构实现的应用程序具有极其良好的可扩展性，是ASP NET面向对象编程的未来方向。  MVC的不足体现在以下几个方面：（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。（4）目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。  三层架构是将代码按其作用分成三部分,每部分解决自己负责的流程. 三层架构的功用之处,在于驾驭大型web程序的结构,使之便于管理和扩展.  在设计UI的时候,我们不需要关心其中的逻辑和数据问题,只需要空出对应的位置,用于放置数据. 在设计和修改的时候,要解决的只是HTML的结构,代码看起来干净利落,做起来也是干净利落.  UI直接将程序逻辑的任务丢给BLL,BLL就开始构建具体的实现细节.BLL的创建依赖于业务. 例如一个文章系统,BLL_Aticle就表示它是用于对文章的处理的.BLL_Aticle可以提供给UI一个文章列表的recordset,显示在UI的预留位置. 当BLL_Aticle需要从数据库中获取数据的时候,就将任务丢给DAL层  DAL层专门负责和数据库打交道,它从BLL获取参数,组织一个有效的SQL,建立数据库连接,执行SQL进行更新或获取,将返回的数据交给BLL.  每一部分的业务都集中于一个UI-BLL-DAL的链中,上下清晰了然. 至于是怎样的便于管理和扩展,将在后面结合实例进行分析.  复杂的生命形式必有复杂的生存法则,若想在自己的项目中应用好三层架构,需要多用点心体会其中的应用法则.  我对三层架构的理解还不够深,这些文章能算是抛砖引玉就不错了.大家在阅读当中不要局限于我所构思的法则,要多向具体的应用中去实践,根据具体情况,寻出自己的法则. 有所感悟,就记得写下来,这种感悟是进步的契机,但必然不是最终的结果.有了感悟就拿去应用,可以发现它的优劣,继续完善  三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。  三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。  三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。  三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
  vs三层架构之间的关系 ？  client -midware -server  可以这样理解：  client 把要求提供给midware  midware 提供服务给 client  midware 把要求提供给server  server 提供服务给 midware  只所以用midware,因为client变化大，  现在不只3层了
  类与类之间的依赖关系是怎样的  对于两个相对独立的系统，当一个系统负责构造另一个系统的实例，或者依赖另一个系统的服务时，这两个系统之间主要体现为依赖关系.
  C#的三层架构各层之间到底怎么传递数据的啊？  可以用属性赋值传，也可以用方法参数传。
  mvc与三层架构的关系是怎么样的  三层是从整个应用程序架构的角度来分的三层（如果程序需要，还可以分多层）。  三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题，为了使程序员更加专注的处理某阶段的业务逻辑。  比如将数据库操作代码封装到一层中，提供一些方法根据参数直接返回用户需要的相应数据，这样在处理具体的业务逻辑的时候，就不用关心数据的存储问题了。  MVC是在应用程序（BS结构）的视图层划分出来的不同功能的几个模块。  MVC主要是为了解决应用程序用户界面的样式替换问题，把展示数据的 HTML 页面尽可能的和业务代码分离。MVC把纯净的界面展示逻辑（用户界面）独立到一些文件中（Views），把一些和用户交互的程序逻辑（Controller）单独放在一些文件中，在 Views 和 Controller 中传递数据使用一些专门封装数据的实体对象，这些对象，统称为Models。  只所以说MVC和三层毫无关系，是因为它们二者使用范围不同：三层可以应用于任何语言、任何技术的应用程序；而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突，可以同时存在，也可根据情况使用其中一种。
   
  三层架构中各层如何传递多个对象  public class Person  {  public string name{get;set;}  public int age{get;set}  }  然后把Person对象传过去就好了
  
  
  传递多个对象，主要看架构者的手段  1.有些人通过Bil去对外提供服务，那么UI的对象依靠bil提供，bil则依靠model或者dal提供  2.有些人通过mvc方式提供，那么他则会根据control控制去获得view视图对象，通过这个视图对象来完成UI到逻辑的传递，至于逻辑本身如何向下传递则同1  ps：其实个人认为不必去管这些，与一些人以一层不变的model不同，我们认为其实各层封装各层自己的viewmodel，你自己根据需要灵活组合，拆解就ok  比如在UI层，为了绑定方便，我们可以有UI的viewmodel  在逻辑层，为了提供不同动作的服务我们则可以继承，组合，装饰，拆解不同对象以提供逻辑层的业务逻辑对象。  而数据层，同样如此。数据库表不等于模型对象，模型对象也不是数据库表。一个模型对象可以被拆分成多个表，一个表可能会是多个模型对象的数据提供。  所以不必强求用一套统一的model去搞定他，要知道OO本身就是封装，继承，多态。你都强行把自己弄成一个一成不变的model，本身就不是OO的对象了。那个是c语言的结构体了
  什么是数学知识之间的依赖关系？  数学知识之间的依赖关系，也就是知识的综合应用问题，知识点之间与知识点之间有练习，对于某些练习题来说，若某些知识点没有及时掌握的话，会影响解题。下面这个例子就是应用数学知识之间的依赖关系解题的。1.在Rt△ABC中（AB是斜边），BC=7cm，AC=24cm，点p在BC上，从B点到C点运动（不包括C点），点P运动的速度为2cm/s；Q点在AC上从C点运动到A点（不包括A点），速度为5cm/s.若点P、Q分别从B、C同时运动。  过程  设P运动x秒时，则BP=2x，CQ=5x  S△PCQ=5x*（7-2x）/2  =-5*（x?? -7x/2+49/16）+245/16  =-5*（x-7/4)??+245/16  即当x=7/4（秒）时，△PCQ的面积最大，最大面积是245/16  2.在ΔABC中,D为BC的中点,E为AC上的任意一点,BE交AD于点O．某学生在研究这一问题时,发现了如下事实: 如图1,当 时,有 ；  如图2,当 时,有 ；  如图3,当 时,有 ；在图4中,当 时,  参照上述研究的结论,请你猜想用n表示AO∶AD的一般结论,并给出证明  结论: AE∶AC=1∶(1+n)时,  AO∶AD=2∶(2+n)．  证明:如图4,作DF‖BE,交AC于F．  ∵BD=DC,∴EF=FC．  ∵AE∶AC=1∶(1+n),∴AE∶EC=1∶n=2∶2n．  ∴AE∶EF=2∶n．  ∴AO∶AD=AE∶EF=2∶(2+n) 【数理化专团作答】
  注入怎么解决组件之间的依赖关系  Spring 从核心而言，是一个DI 容器，其设计哲学是提供一种无侵入式的高扩展性框架。即无需代码中涉及Spring专有类，即可将其纳入Spring容器进行管理
   

7. 三层架构的三层具体作用

三层结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL)
1：数据数据访问层:主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不

是指原始数据，也就是说，是对数据的操作，而不是数据库,具体为业务逻辑层或表示层提供数据服务．


2：业务逻辑层:主要是针对具体的问题的操作，也可以理解成对数据层的操作,对数据业务逻

辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。


3：表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成

:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地

提供服务。

8. 三层架构的含义特点是什么

三层架构2007-08-14 10:30IT行业的一大特点是经常创造一些新名词，单层和双层这两个概念就是在三层结构出现之后才创造出。单层结构是80年代以来小型应用的结构，典型的是基于Dbase、Foxbase等小型数据库的应用。双层结构的同义词可以理解为传统的客户/服务器结构，是目前占统治地位的结构，典型是基于Oracle、Infomix等大型数据库的应用。三层结构是传统的客户/服务器结构的发展，代表了企业级应用的未来，典型的有Web下的应用。多层结构和三层结构的含义是一样的，只是细节有所不同。

   之所以会有双层、三层这些提法，是因为应用程序要解决三个层面的问题。

一：界面层

   界面层提供给用户一个视觉上的界面，通过界面层，用户输入数据、获取数据。界面层同时也提供一定的安全性，确保用户有会看到机密的信息。

二：逻辑层

   逻辑层是界面层和数据层的桥梁，它响应界面层的用户请求，执行任务并从数据层抓取数据，并将必要的数据传送给界面层。

三：数据层

   数据层定义、维护数据的完整性、安全性，它响应逻辑层的请求，访问数据。这一层通常由大型的数据库服务器实现，如Oracle 、Sybase、MS SQl Server等。

三层架构的优势

   从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。

   三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。我的机器是奔腾133、32M内存、2.5G硬盘，装了IE4.0之后，感觉机器慢子很多，硬盘也只有300多M的空余空间了，已打算将硬盘扩充到4G。试想如果今后还是以单层或双层峁刮主流的话，硬件的更新费用将会有多大，尽管现在电脑价格下降很多，对个人用户已可以承受，但对于企业而言，频繁的台旧机器淘汰，换新机器，这是一笔多么大的费用

   三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。美国人曾利用分式计算解密，几个月就破解了据称永远都破不了的密码。

   三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。

如何开发三层应用

   支持三层应用开发的工具很多，VC 5.0、Delphi 3.0、VB 5.0都是不错的选择，而Delphi是其中功能强大而有相对容易的开发工具。

   Delphi 3针对3层结构，提出了三种代理（Broker)和新一代的数据库引擎，来适应它。

   第一种叫Remote Data Broker, Remote Data Broker结构的精髓是让每一个客户端不再需要BDE，取面代之的是中央化的BDE，以集中管理的方式降低每一个客户在BDE上所须调整的开销和复杂度。第二种叫Constraint Broker，它所扮演的角色就是保证所有客户数据的一致性和数据的完整性。第三种是Business Object Broker，它的目的是提供给一些关键性的商业应用程序一个快速而且可信赖的使用环境。为了达成这种高层次的要求，BusinessObjectBroker会自动的将应用程序做适当的划分，并复制重要的业务规则到第一个区间，以达到速度的要求

总结。

   伴随着企业自身的发展和外部环境的复杂化，企业的需求也越来越复杂，应用程序的开发也更加困难。三层客户/服务器架构将有助于解决这一问题。