三层架构和其优点
Java_三层架构与mvc
一、三层架构：1．数据访问层：主要是对原始数据（数据库或文本文件等存放数据的形式）的操作，而不是数据本身，是“操作数据库”，而不是“数据库”，为业务逻辑层和表示层提供数据服务。
2.业务逻辑层：主要是针对具体的问题，对数据业务逻辑处理，主要负责对数据层的操作，把一些数据层的操作组合。
3.表示层：主要对用户数据的接受，以及数据的返回，为客户端提供应用程序的访问。
二、三层架构的优缺点：优点：1.开发人员可以只关注结构中的某一层2.可以很容易的用新的实现来替代原有结构中的一层3.可以降低层和层之间的依赖4.可以更容易实现标准化5.有利于各层的复用6.结构更加清晰7.大大降低后期维护成本和维护时间缺点：1.降低了系统的性能，如果不采用三层架构，很多业务可以直接访问数据库，以此来获取数据，而现在必须通过中间层来获取数据。
2.有时候会产生级联修改，尤其体现在自上而下的修改，比如在表示层需要增加一个功能，那么为了保证其设计符合分层式结构，那么在业务逻辑层和数据访问层都要增加相应的代码。
3.增加了开发成本二、三层架构和MVC的比较：MVC是一种架构模式，不是设计模式。
同样是架构级别，相同的地方是他们都有一个表现层，不同在于其他两层。
在三层架构中没有定义Controller的概念，这是主要的不同的地方，而MVC也没有把业务的逻辑访问堪称两个层，这是采用三层架构和MVC搭建程序的主要区别，当然了，在三层中也提到了Modle,但是和MVC中的Modle还是有区别的，“三层”中典型的modle层是实体类组成的，而MVC中的Modle则是有业务逻辑和访问数据构成的。
四、MVC1.Modle(模型)是应用程序用来处理数据业务逻辑的部分，通常模型对象负责在数据库中存取数据2.view(视图)是应用程序中处理数据显示的部分，视图通常是依据模型数据创建的。
3.controller(控制器)是应用程序中处理用户交互的部分，通常控制器负责从视图接收数据，控制用户输入，并向模型发送数据。
三层架构详解范文
三层架构详解范文三层架构是一种软件设计模式，将应用程序分为三个主要层次：表示层、业务逻辑层和数据访问层。
每个层次都具有不同的职责和功能，使得系统更易于维护、扩展和测试。
1.表示层：表示层是用户与系统之间的接口，负责接收用户输入、展示输出结果。
它是系统的外部界面，可以是一个网页、桌面应用程序、移动应用程序等。
表示层通常包括用户界面设计、用户体验设计和前端开发等方面，它负责与用户进行交互，将用户的请求传递给业务逻辑层进行处理，并将处理结果展示给用户。
2.业务逻辑层：业务逻辑层是系统的核心，负责处理系统的业务逻辑。
它包括了业务规则、工作流程和数据处理等方面。
业务逻辑层接收来自表示层的请求，根据业务规则进行数据处理和业务逻辑的计算，最后将结果返回给表示层。
在这个层次上，开发人员可以将系统的业务逻辑进行封装，使得系统的可复用性和可维护性更高。
3.数据访问层：数据访问层是负责对数据进行持久化存储和访问的层次。
它包括了数据库的管理和访问，以及与其他数据源的交互等。
数据访问层将业务逻辑层的数据请求转化为数据库操作，通过与数据库进行交互来进行数据的增删改查。
在这个层次上，开发人员可以实现数据缓存、事务管理、数据访问的优化等功能。
三层架构的主要优点有：1.松耦合：三层架构将整个系统分为三个独立的层次，各层次之间通过接口进行交互，使得各层次之间的耦合度降低。
这样，在修改或拓展其中一层次的功能时，不会对其他层次造成影响，提高了系统的灵活性和可维护性。
2.可扩展性：由于每个层次都有明确的功能和职责，因此可以很容易地拓展系统的功能。
例如，可以通过增加实现新的表示层、业务逻辑层或者数据访问层来实现系统功能的扩展。
3.可测试性：每个层次的功能相对独立，因此可以单独对每个层次进行测试。
这样可以更容易地进行单元测试和集成测试，提高了系统的可测试性和稳定性。
4.可维护性：三层架构将系统分为多个层次，使得每个层次的功能和职责更加清晰明确，减少了系统的复杂性。
数据库系统的三级模式结构这种结构的优点是什么
数据库系统的三级模式结构这种结构的优点是什么数据库系统的三级模式结构由外模式、概念模式和内模式组成。
外模式是用户对数据库中其中一部分数据及其结构的描述，概念模式是数据库的全局逻辑结构和所有用户的公共视图的描述，内模式是数据库在存储介质上的实际存储结构。
这种三级模式结构的优点主要有以下几点：1.数据独立性：三级模式结构实现了数据与应用之间的逻辑独立性和物理独立性。
逻辑独立性指应用程序与数据的逻辑结构相互独立，应用程序可以独立于数据库的逻辑存储结构进行设计。
物理独立性指应用程序与数据的物理存储结构相互独立，应用程序可以独立于数据库的物理存储结构进行设计。
2.数据共享和一致性：概念模式是数据库系统的全局逻辑结构和所有用户的公共视图的描述。
通过概念模式，多个用户可以共享数据库中的数据，实现数据的共享和一致性。
用户不需要了解数据库内部的存储细节，只需要根据自己的需要定义外模式。
3.数据安全性和完整性：通过三级模式结构，可以实现对数据的安全性和完整性的控制。
概念模式中可以定义数据的约束条件和安全性控制，包括完整性约束、域约束、参照约束等。
而外模式可以进一步定义针对用户的安全性和完整性需求的约束。
4.数据存储效率和性能优化：由于概念模式与物理存储结构分离，可以根据实际需求对数据库进行物理存储结构的优化，包括索引构建、存储分区、数据压缩等。
这样可以提高数据库的存储效率和查询性能。
总之，数据库系统的三级模式结构通过逻辑独立性和物理独立性的实现，实现了数据与应用之间的解耦。
用户无需关心数据库的内部存储结构，只需要根据自己的需要定义对数据的视图，实现了数据的共享、安全性和完整性的控制。
同时，通过对数据库的物理存储结构进行优化，可以提高数据库的存储效率和查询性能。
这种结构的优点使得数据库系统成为了现代信息系统中最重要的组成部分之一。
系统三层架构优势
系统三层架构优势
安全维护方面：
1.一键安装，自动升级。
2.系统灾难后,恢复快。
例如：被病毒破坏，需重装系统。
3.数据展现，可进行类似Excel的操作,对数据进行过滤\排序\计算\导出excel的操作等。
4.数据录入与c/s系统相同的录入界面，支持纯键盘录入。
响应速度方面：
1.可支持每秒40KB流量的网络。
2.保证系统的正常运行。
3.可支持南网通北电信的跨网使用。
外部设备的访问方面：
1.可以支持钱箱打开。
2.可支持小票的套打。
3.可连接外接指纹考勤机。
4.可支持顾客显示频。
5.可支持人流计数器。
6.可支持银行刷卡机。
数据传送压力方面：
1.数据流量小。
2.数据传送稳定。
3.离线、在线混合使用。
服务器压力及网络压力方面：
1.一台3万元的服务器再加3M的光钎可支持150家店铺使用。
数据安全方面：
1.可与控制专卖店使用的电脑其地址。
2.可实时跟踪客户所使用的IP地址和使用的电脑。
3.可控制用户使用的时间段。
J2EE三层架构及其优越性
J2EE 的三层架构：
J2EE 与传统的CS 之间的优缺点：
J2EE 的优越性：
1.保留现存的IT 资产：可以充分利用原有的投资，由于基于J2EE 平台的产品几乎能在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。
2.高效的开发：J2EE 允许公司吧一些通用的，很繁琐的服务端任务交给中间件供应商取完成。
这样开发人员可以集中精力在如何创建商业逻辑上，相应缩短开发时间。
3.支持异构环境：J2EE 能够开发部署在异构环境中的可移植程序，基于J2EE 的应用程序不依赖于任何特定操作系统，中间件，硬件，因此设计合理的基于J2EE 的程序只需开发一次就可部署到各种平台。
也允许客户订购与J2EE 兼容的第三方的组成的组件，把他们部署到异构环境中，节省了由自己制定整个方案所需的费用。
4.可伸缩性;J2EE 领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署，这种部署可达数千处理器，实现可高度伸缩的系统，满足未来商业的需求。
5.稳定的可用性：J2EE 部署到可靠的操作系统中，他们支持长期的可用性。
CS 的不足：有一个庞大的客户端，并且在数据安全性要求不高的应用中，对于网络联通过于依赖。
客户端需要安装专用的客户端软件及运行环境。
对于版本更新等操作业务复杂。
系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。
表现层 客户端组件 主要功能在于数据的显示，数据如何表现。
应用层 1.业务功能子层 2.应用平台子层 主要是对于业务的处理以及数据的处理。
数据层 1.数据访问子层 2.数据管理子层
主要是实现与数据库的交互。
三层架构详解
随着软件工程的不断进步和规范以及面向对象编程思想的应用，人们对封装、复用、扩展、移置等方面的要求，使 得双层架构显然更加臃肿繁琐，三层程序架构体系应 运而生，可以说，三层架构体系结构是面向对象思想发展中的必 然产物。 当然三层架构对于目前来说早已经不是什么新鲜事物了,最早听到这个词应该是几年前使用 java 知道的吧，j2ee 三层架构体系流行了这么多年， 一直没有使用过,不过 j2ee 三层架构体系的提出， 对软件系统的架构产生了巨大的影响， Microsoft 、Boland 这些公司自然不甘落后，例如 Microsoft 的.net 平台，更有甚者，称 .net 之 c#为 java 的儿子。那么何 谓三层架构？所谓三层架构，是在客户/服务之间加入了一个"中间层 "，也叫组件层。它与客户层、服务器层共同构成 了三层体系。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有 B/S 应用才有三层体系结构，三层是指逻辑上的三层。通过引入中间层，将复杂的商业逻辑从传统的双层结构 (Client-Server)应用模型中分离出来，并提供了可伸缩、易于访问、易于管理的方法，可以将多种应用服务分别封装部署 于应用服务器，同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性，使用户在管理上所花费的时 间最小化，从而实现了便捷、高效、安全、稳定的企业级系统应用。 1.3 分层描述三层架构 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直 接与数据库进行交互，而是中间层向外提供接口，通过 COM/DCOM 通讯或者 Http 等方式与中间层建立连接，再经由 中间层与数据库进行交互。当然数据通过中间层的中转无疑是降低了效率，但是它脱离于界面与数据库的完美封装，使 得它的缺点显然不值得一提。
具有高可维护性的软件应用三层架构的分析
具有高可维护性的软件应用三层架构的分析介绍三层架构是一种常见的软件架构，它将软件系统分为三个层次：表现层、应用层和数据层。
表现层是用户接口，应用层是系统的业务逻辑，数据层是数据存储。
三层架构有很多优点，其中一个重要的优点是高可维护性。
在本文中，我们将分析三层架构的高可维护性，以及如何设计具有高可维护性的软件应用。
高可维护性的三层架构高可维护性是三层架构的一个重要优点。
这是因为它可以将系统的不同功能分开，不同的职责分配给不同的层。
例如，表现层和应用层可以独立于数据层进行维护，而不会影响其他层。
表现层的维护表现层通常是用户界面，包括网页框架、窗体和报表等。
这些界面通常是由设计师和开发人员合作设计完成的，这使得界面的功能和布局具有一定的灵活性。
在三层架构中，表现层与其他层不直接交互。
因此，在维护表现层时，可以在不影响其他层的情况下，修改和更改界面和布局。
这包括了改变元素的背景颜色、字体、布局等，而不会影响系统的核心业务逻辑。
应用层的维护应用层是连接表现层和数据层的层，负责处理业务逻辑。
它包括数据验证、计算和处理用户输入、生成报表等。
在设计应用层时，应该考虑到业务逻辑的变化。
可以使用设计模式来实现应用层的灵活性，例如工厂模式、策略模式等。
这些模式可以使应用层具有扩展性和可组合性，从而支持系统未来的变化和需求。
这也提高了应用层在修改不同模块时的可维护性。
数据层的维护在三层架构中，数据层是负责处理数据的地方。
它可以是这样的存储方式：数据可存储在一个常规文件、数据库或其它的数据仓库中。
在数据层的维护时，需要考虑到数据的持久性以及对数据的访问。
这意味着需要考虑如何最好地组织数据，以供不同的应用程序访问，并运用最先进的数据库技术个管理数据。
在数据处理过程中，需要应用合理的数据模型和分账设计，使得在数据增长和变化时，数据层可以随之变动而不影响其他层的正常运行。
提高三层架构的可维护性下面是提高三层架构可维护性的一些奉献：- 应用设计模式设计模式在提高系统可维护性方面起到了很大的作用。
三层架构利弊及用法
三层架构利弊及⽤法名词解释架构：架构⼀般是针对整个系统的，并⾮针对某个单独的问题（单独问题可以⽤模式等来解决）针对整个系统的”⼀个蓝图”，对系统的抽象。
模式：软件开发中遇到的⼀些特定问题，前⼈总结出来特定的经验、解决⽅法。
框架：架构设计、模式应⽤的经验积累的具体代码实现，⽅便以后的复⽤。
三层表现层UI（User Interface）：通俗讲就是展现给⽤户的界⾯，即⽤户在使⽤⼀个系统的时候他的所见所得。
业务逻辑层BLL（Business Logic Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
（备注：⼜称领域层，常⽤于业务规则、数据访问、合法性校验）数据访问层DAL（Data Access Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
（领域对象：crud）（新的：逻辑层就像房屋中介，租房买房更快捷了，但消耗的钱也更多了。
）优点：1、开发⼈员可以只关注整个结构中的其中某⼀层；2、可以很容易的⽤新的实现来替换原有层次的实现；3、可以降低层与层之间的依赖；4、有利于标准化；5、利于各层逻辑的复⽤。
6、结构更加的明确7、在后期维护的时候，极⼤地降低了维护成本和维护时间缺点：1、降低了系统的性能。
这是不⾔⽽喻的。
如果不采⽤分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在⾃上⽽下的⽅向。
如果在表⽰层中需要增加⼀个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本。
规则：三层结构的程序不是说把项⽬分成DAL,BLL,WebUI三个模块就叫三层了，下⾯⼏个问题在你的项⽬⾥⾯：⒈ UILayer⾥⾯只有少量（或者没有）SQL语句或者存储过程调⽤，并且这些语句保证不会修改数据?⒉如果把UILayer拿掉，你的项⽬还能在Interface/API的层次上提供所有功能吗?⒊你的DAL可以移植到其他类似环境的项⽬吗?⒋三个模块，可以分别运⾏于不同的服务器吗?如果不是所有答案都为YES，那么你的项⽬还不能算是严格意义上的三层程序. 三层程序有⼀些需要约定遵守的规则：⒈最关键的，UI层只能作为⼀个外壳，不能包含任何BizLogic的处理过程⒉设计时应该从BLL出发，⽽不是UI出发. BLL层在API上应该实现所有BizLogic，以⾯向对象的⽅式⒊不管数据层是⼀个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在⼀定的抽象程度上做到系统⽆关⒋不管使⽤COM+(Enterprise Service），还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群所以考虑⼀个项⽬是不是应该应⽤三层/多层设计时，先得考虑下是不是真的需要? 实际上⼤部分程序就开个WebApplication就⾜够了，完全没必要作的这么复杂. ⽽多层结构，是⽤于解决真正复杂的项⽬需求的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
三层架构及其优点(2009-04-01 22:54:37)标签：三层架构是：一：界面层界面层提供给用户一个视觉上的界面，通过界面层，用户输入数据、获取数据。
界面层同时也提供一定的安全性，确保用户不用看到不必要的机密信息。
二：逻辑层逻辑层是界面层和数据层的桥梁，它响应界面层的用户请求，执行任务并从数据层抓取数据，并将必要的数据传送给界面层。
三：数据层数据层定义、维护数据的完整性、安全性，它响应逻辑层的请求，访问数据。
这一层通常由大型的数据库服务器实现，如Oracle 、Sybase、MS SQl Server等。
------从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。
三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。
开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。
三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。
相比之下，单层或胖客户对面器的要求太高。
三层架构的另一个优点在于可以更好的支持分布式计算环境。
逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。
分布式计算的潜力巨大，远比升级CPU有效。
三层架构的最大优点是它的安全性。
用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
另外三层架构还可以支持如下功能：Remote Access(远程访问资料)，例如可透过Internet存取远程数据库；High Performance(提升运算效率)解决集中式运算(Centralize)及主从式架构(Client-Server)中，数据库主机的运算负担，降低数据库主机的Connection Load，并可藉由增加App Server处理众多的数据处理要求，这一点跟前面讲到的分布式计算提高运算能力是一个道理；Client端发出Request(工作要求)后，便可离线，交由App Server和DataBase Server共同把工作完成，减少Client端的等待时间；这个功能我觉得应用场合不是很多，自己感受也不是很深刻，从理论上是成立的。
--fadeless摘自网络。
三层架构三层系统的分层式结构三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。
区分层次的目的即为了“高内聚，低耦合”的思想。
目录展开概念简介１、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
２、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
３、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
概述在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。
推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层。
三层结构原理：3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。
所谓三层体系结构，是在与数据库之间加入了一个“中间层”，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。
表示层位于最外层（最上层），离用户最近。
用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
业务逻辑层业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。
它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。
例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。
作为的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。
由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。
如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。
因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。
正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。
对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。
依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给的任务。
数据层数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问、二进制文件、或是XML文档。
简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。
如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。
优点1、开发人员可以只关注整个结构中的其中某一层；2、可以很容易的用新的实现来替换原有层次的实现；3、可以降低层与层之间的依赖；4、有利于标准化；5、利于各层逻辑的复用。
缺点1、降低了系统的性能。
这是不言而喻的。
如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在自上而下的方向。
如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
规则三层结构的程序不是说把项目分成DAL, BLL, WebUI三个模块就叫三层了, 下面几个问题在你的项目里面：1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用, 并且这些语句保证不会修改数据?2. 如果把UILayer拿掉, 你的项目还能在Interface/API的层次上提供所有功能吗?3. 你的DAL可以移植到其他类似环境的项目吗?4. 三个模块, 可以分别运行于不同的服务器吗?如果不是所有答案都为YES, 那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则：1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以的方式3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了, 完全没必要作的这么复杂. 而, 是用于解决真正复杂的项目需求的。
与MVC的区别MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
在三层架构中没有定义Controller的概念。
这是我认为最不同的地方。
而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。
当然了。
在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model 的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
三层架构有表示层，业务逻辑层，数据处理层就像餐厅，客官看菜单点菜（表示层），服务员处理点的菜（业务逻辑层），再将点的菜单传给厨师（数据处理层），厨师炒好后给服务员传给客官如是不用三层，全部由厨师来处理是不是太那个了，如果是小饭店倒是可以由厨师处理优点：1。
扩展性强，不同层负责不同的层面，如PetShop可经过简单的配置实现Sqlserver和oracle之间的转换，当然写好了也可以实现B/S与C/S之间的转换。
2。
利于实现人员分工；缺点：增加工作量、代码编写量三层架构学习笔记作者：厚朴教育来源：本站原创点击数：368 更新时间：2010-7-26 三层架构如下图所示：三层架构分为：表现层（User Interface，简称UI）、业务逻辑层（Bus iness Logical Layer，简称BLL）、数据访问层（Data Access Layer，简称DAL）。
三层架构的优点是能让项目更容易修改、更有扩展性、更有复用性、可迁移、刚开始是为C/S模式而开展的，后来慢慢扩展到B/S模式。
三层架构并不能提高项目的运行效率，相反由于表现层只能访问逻辑层，再逻辑层访问数据访问层，因此牺牲了效率。
但这一缺陷比起它的优势，在现在硬件品质高速发展的时代几乎可以忽略不计。
三层架构能提高数据库访问效率和安全性，原因有三：1、数据层不包含任何代码，只有数据库，还有相关的存储历程。
2、数据层还包含所有公共数据造访代码。
3、所有数据读取都放在数据层。
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。
数据访问层(DAL)：也可称为持久层，其功能主要是负责数据库的访问。
在PetShop中处理的数据库对象分为两类：一是数据实体(Model)，对应数据库中相应的数据表，他们没有行为，仅用于表现对象的数据；二是数据的基本业务操作，即完成一般的数据操纵，这部分采用了抽象工厂模式，即保证了系统的可扩展性，同时也保证了数据库的可移植性。