软件工程开发三层架构的具体功能和区别是什么?数据层,业务逻辑层,UI层.
数据层顾名思义就是对数据的操作 业务成就是对其软件的具体业务描述与整合 UI层就是我们看到的操作界面 你说的两层是物理上的 这是引入面向对象理念便于软件的维护等oop的有点都有
.NET分层是怎么回事 三层架构与其又有什么关系，能否帮忙简单介绍一下三层架构？
三层结构是现在开发中常用的开发模式
三层构架即MVC（model-view-control）
model：模型层，这里主要放置业务逻辑，也就是处理的一些方法，包括数据的交互
view：视图层，这里就是做出来呈现给客户的界面，即网页或客户端的一些窗体界面
control：控制层，这里组要负责业务逻辑的调用，以及返回的页面控制，就好比交通的指挥中心
分布式应用开发简单的说，是指将用户界面、控制台服务、数据库管理三个层次部署在不同的位置上。其中用户界面是客户端实现的功能，控制台服务是一个专门的服务器，数据管理是在一个专门的数据库服务器上实现的。
软件工程的方法也就是从软件的可行性分析→项目计划→需求分析→概要设计→详细设计→编码→测试→维护。这样一系列的步骤进行科学的开发。掌握软件工程的方法对于软件开发的好与坏有着重要的关联。
请问软件三层架构是如何架构的,用什么工具开发?
MVC架构模式基于Java的Web应用系统采用MVC架构模式,即model(模型)、view(视图)、control(控制)分离设计.这是目前WEB应用服务系统的主流设计方向.Model:即处理事务逻辑的模块,每一种处理一个模块.View:视图负责页面显示,负责显示MODEL处理结果给用户,主要实现数据到页面转换过程.Control:控制负责每个请求request的分发dispatch,把FORM数据传递给MODEL处理,把处理结果的数据传递给VIEW显示.Eclipse、WebLogic、WebSphere都是基于MVC设计模式的J2EE开发工具
如何理解计算机软件系统的分层结构
这就好比建一座大楼: 最底层的是搬砖头的民工 再上一层是建筑梁、墙的工人,它们可以指挥民工(在计算机里,称为调用下层的服务) 再上一层是包工头,指挥工人完成某个单元的施工(调用工人的服务) 再上一层是工程师,指挥包工头工作(调用包工头的服务) 就是这样,下层为上层服务,上层调用下层的服务,越是下层做的工作越基础
软件架构模式基本概念及三者区别
在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。
架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。
代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
架构模式(Architectural Pattern)
一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。称之为系统模式。
•MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
•Layers（分层）模式，有时也称Tiers模式
•Blackboard（黑板）模式
•Broker（中介）模式
•Distributed Process（分散过程）模式
•Microkernel（微核）模式
架构模式常常划分成如下的几种：
一、 模块结构(From Mud to Structure)型。帮助架构师将系统合理划分，避免形成一个对象的海洋。包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
二、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
三、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
四、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection（反射）模式、Microkernel（微核）模式等。
设计模式(Design Pattern)
一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：
创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等
行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。设计模式在特定的编程语言中实现的时候，常常会用到代码模式。比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。
代码模式(Coding Pattern)
代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等
三层架构和MVC架构模式.
三层架构是一个分层式的软件体系架构设计,它可适用于任何一个项目.三层架构将整个项目划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL). MVC是一个设计模式,它是根据项目的具体需求来决定是否适用于该项目.MVC可分为:Model模型层、View视图层、Controller控制层; 总结:在Java web开发中,MVC框架充当了UI层和业务逻辑层的适配器的作用.MVC框架实现了UI层和业务逻辑层最大程度的分离.
阐述在java中是如何分层的，可以介绍MVC架构，以一个简单的实例说明
MVC模式。
Model模式层
View视图层
Controller控制器
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
MVC的一个形象的例子，我要去买一辆奔驰车，那么我先要去4S店，那么这个店面就是控制层，他不会关心车子是什么制造的，只管提供车给我。那么车厂就是SERVICE层，他只管制造车子，把结果提供给4S店，那车子的零件又是怎么来的呢？他就是通过更多的零件厂商来提供，那么这些零件厂商就是DAO层。
软件三层结构
何谓B/S结构，就是只安装维护一个服务器（Server），而客户端采用浏览器（Browse，如Internet Explorer，MYIE等）运行软件，即浏览器/服务器结构。
相对于C/S结构，尽管C/S结构相对于更早的文件服务器来说，有了很大的进步，但与B/S相比，缺点和不足是很明显的。
1.首先，B/S比C/S的维护工作量大大减少了。C/S结构的每一个客户端都必须安装和配置软件。假如一个企业共有50个客户站点使用一套C/S结构的软件，则当这套软件进行了哪怕很微小的改动后（比如增加某个功能），系统维护员都必须进行这样的维护；将服务器更新到最新版本；将客户端原有的软件卸载，再安装新的版本，然后进行设置，最为可怕的是客户端的维护工作必须不折不扣的进行50次。若其中有部分客户端是在另外一个地方，则系统维护员还必须跑到该地方再进行卸载、安装、设置的工作。 若某个客户端，忘记进行这样的维护，则该客户端将会碰到版本不一致的问题而无法工作。 而B/S结构，客户端不必安装及维护。如果我们将前面企业的C/S结构的软件换成B/S结构的，我们看看软件升级后，系统维护员如何维护： 系统维护员只要将服务器的软件升级到最新版本就行了。其他客户端，只要重新登录系统，使用的就已经是最新版本的软件了。
2.其次，B/S相对C/S能够降低总体拥有成本， C/S软件一般是采用两层结构的。
两层结构中，客户端接受用户的请求，客户端向数据库服务提出请求，数据库服务将数据提交给客户端，客户端将数据进行计算（可能涉及到运算、汇总、统计等等）并将结果呈现给用户。
在三层结构中，客户端接受用户的请求，客户端向应用服务提出请求，应用服务从数据库服务中获得数据，应用服务将数据进行计算并将结果提交给客户端，客户端将结果呈现给用户。
这两种结构的不同点是，两层结构中客户端参与运算，而三层结构中客户端并不参与运算，只是简单的接收用户的请求，显示最后的结果。由于三层结构中的客户端并不需要参与计算，所以对客户端计算机的配置要求是比较低的。
另外，由于从应用服务到客户端只传递最终的结果，数据量较少，使用电话线也能够信任。而采用C/S两层结构，使用电话线作为传输线路可能因为速度太慢而不能够接受。 采用三层结构的璐华软件的配置可以是提高服务器的配置，降低客户端的配置。这样增加的只是一台服务器（应用服务和数据库服务可以放在同一台计算机中）的价格，而降低的却是几十台客户端机器的价格。起到了降低总体拥有成本的作用。
C/S、B/S软件数据一致性比较
在C/S结构软件的解决方案里，对于异地经营的大型集团都采用各地安装区域级服务器，然后再进行数据同步的模式。这些服务器每天必须同步完毕之后，总部才可得到最终的数据。由于局部网络故障造成个别数据库不能同步不说，即使同步上来，各服务器也不是一个时点上的数据，数据永远无法一致，不能用于决策。对于B/S结构的软件来讲，其数据是集中存放的，客户端发生的每一笔业务单据都直接进入到中央数据库，不存在数据一致性的问题。
C/S、B/S软件数据实时性比较
在集团级应用里，C/S结构不可能随时随地看到当前业务的发生情况，看到的都是事后数据；而B/S结构则不同，它可以实时看到当前发生的所有业务，方便了快速决策，有效地避免了企业损失。
C/S、B/S软件数据安全性比较
由于C/S结构软件的数据分布特性，客户端所发生的火灾、盗抢、地震、病毒、黑客等都成了可怕的数据杀手。另外，对于集团级的异地软件应用，C/S结构的软件必须在各地安装多个服务器，并在多个服务器之间进行数据同步。如此一来，每个数据点上的数据安全都影响了整个应用的数据安全。所以，对于集团级的大型应用来讲，C/S结构软件的安全性是令人无法接受的。对于B/S结构的软件来讲，由于其数据集中存放于总部的数据库服务器，客户端不保存任何业务数据和数据库连接信息，也无需进行什么数据同步，所以这些安全问题也就自然不存在了。
ASP.NET程序设计(2.) 描述三层架构具体分为哪几层以及每层需要实现的功能. 求
http://www.cnblogs.com/kelvin0916/archive/2012/09/24/2700264.html 参考一下现成的帖子吧. 三层架构主要是数据层,业务逻辑层和UI层.这是比较老的分层架构了.现在微软也好,其他框架也好,都推出了MVC架构,我个人认为更加好吧.至于每层的功能嘛,数据层主要是进行数据库操作,交互读写等,业务逻辑就是实现网站或者APP的真正的业务功能.UI层就是做数据展示,用户交互等.
什么是模式、框架？软件为什么要分层？
有次朋友问什么是模式？我也在学习中，就我的学习经验，给出以下小结。（注意：个人观点，仅供参考，欢迎指正。） 1．什么是模式？ 模式，即pattern。其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度，那就是模式。Alexander给出的经典定义是：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。模式有不同的领域，建筑领域有建筑模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现很多模式。 2．什么是框架？ 框架，即framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。 3．为什么要用模式？ 因为模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。 4．为什么要用框架？ 因为软件系统发展到今天已经很复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。 5．软件为什么要分层？ 为了实现”高内聚、低耦合”。把问题划分开来各个解决，易于控制，易于延展，易于分配资源…总之好处很多啦：）。 评论： 如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。所以我们希望在软件系统构建过程中，人和机器发挥各自的长处，也就是说，让人来扮演架构师的角色，而让机器来扮演程序施工者的角色。
