架构模式，常用的软件架构及设计模式net为例

本文目录一览

1，常用的软件架构及设计模式net为例
2，企业架构管理
3，试问设计模式架构模式和架构风格的异同点
4，什么是设计模式和架构模式之间的区别
5，什么是架构
6，三层架构和mvc模式有什么关系

1，常用的软件架构及设计模式net为例

10年前常用的是三层架构，现在还有很多“散户”在用这种设计模式。如今主流的有两种，一个是MVC，这个需要下载相应的VS插件；另一个就是.NET版的Hibernate，叫NHibernate，这个在大型的商业应用程序中常用到，但主要用于开发Web端。

三层架构 MVC再看看别人怎么说的。

三层架构 MVC

常用的软件架构及设计模式net为例

2，企业架构管理

你那什么企业我不知道，我按我们的说吧： A：董事会（监事会） B：总经理 C：副总经理 D:办公室-人事部-财政部-企业管理部-监察审计部-安全监督部（生产经营部）以下是：属下企业、合作单位如果说的不够清楚、我们可以单聊、我把图发给你

一个企业的构架管理：首先是董事长下面设总经理——下面设行政——财务——营销等等，如果有生产型企业的话在设生产管理的部门，就是这样层层管理的框架。

企业架构管理

3，试问设计模式架构模式和架构风格的异同点

设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。架构模式从子系统或模块、及其之间的关系层次上描述了粗粒度的解决方案。架构风格是描述某一特定应用领域中系统组织方式的惯用模式，是系统主要的、组织性的设计。风格是模式的外在表现。三者的共同点是都用于设计，是一套可重用的方法套路。不同点：前二者的不同点在于粒度，设计模式定义出子系统或组件的微观结构，结架构模式则从子系统或模块、及其之间的关系层次上描述了粗粒度的解决方案；后二者的区别在于前者着重描述系统的内部组织，后者着重于描述结构的外在表现。

架构风格描述客户端-服务器将系统分为两个应用，其中客户端向服务器发送服务请求。基于组件的架构把应用设计分解为可重用的功能、逻辑组件，这些组件的位置相互透明，只暴露明确定义的通信接口。分层架构把应用的关注点分割为堆栈组（层）。消息总线指接收、发送消息的软件系统，消息基于一组已知格式，以便系统无需知道实际接收者就能互相通信。 n层/三层架构用与分层风格差不多一样的方式将功能划分为独立的部分，每个部分是一个层，处于完全独立的计算机上。面向对象该架构风格是将应用或系统任务分割成单独、可重用、可自给的对象，每个对象包含数据，以及与对象相关的行为。分离表现层将处理用户界面的逻辑从用户界面（ui）视图和用户操作的数据中分离出来。面向服务架构（soa）是指那些利用契约和消息将功能暴露为服务、消费功能服务的应用。这些架构风格分别适用于特定领域：分类架构风格通信 soa，消息总线，管道和过滤器部署客户端/服务器，三层架构，n层架构领域领域模型，网关交互分离表现层结构基于组件的架构，面向对象，分层架构

试问设计模式架构模式和架构风格的异同点

4，什么是设计模式和架构模式之间的区别

设计模式是架构的手段（之一）。　　具体一点说，设计模式可以在某些情况帮助架构软件的静态结构。　　而架构的范围要大一些，更高层一些，考虑的更多的是非常重要的全局性的design decision。一般好的（静态）架构可以尽量使变化发生在局部（模块内）而不影响整个系统。架构上的变化往往成本会非常高。　　而且设计模式只有一些是适用于架构的，还有一些只是用于具体的类设计的，剩下的一些则只是克服编程语言的限制而已。　　打个不恰当的比方，有点像挡拆和战术的关系。　　在合适的情况下用好挡拆可以很好的执行战术，　　但战术不只有挡拆，　　而且有的战术不需要挡拆，　　最重要的是盲目的用挡拆有时候反而会起反作用。　　面对客户哔哔时，我们用需求分析架构。　　面对整个软件或系统时，我们谈论架构分析。　　面对软件模块设计时，我们使用设计模式。　　面对模块实现时，我们应用特定编程语言的特性。　　软件架构：一般场景下拥有设计的选择权　　设计模式：选择后特定场景下的最佳实践　　软件架构是软件的一种搭建形式，往往规定了软件的模块组成，通信接口（含通信数据结构），组件模型，集成框架等等。往往规定了具体的细节。　　设计模式是一种软件的实现方法，是一种抽象的方法论，是为了更好的实现软件而归纳出来的有效方法。　　实现一种软件架构，不同组成部分可能用到不同的设计模式，某一部分也可能可以采用不同的设计模式实现。

云计算——至少作为虚拟化的一种延伸，影响范围已经越来越大。但是，目前云计算还不能支持复杂的企业环境。因此云计算架构呼之欲出，经验表明，在云计算走向成熟之前，我们更应该关注系统云计算架构的细节。基于对现有的一些云计算产品的分析和个人一些经验，总结出一套云计算架构，云计算架构主要可分为四层。显示层多数数据中心云计算架构的这层主要是用于以友好的方式展现用户所需的内容和服务体验，并会利用到下面中间件层提供的多种服务，主要有五种技术： html：标准的web页面技术，现在主要以html4为主，但是将要推出的html5会在很多方面推动web页面的发展，比如视频[1]和本地存储等方面。 javascript：一种用于web页面的动态语言，通过javascript，能够极大地丰富web页面的功能，并且用以javascript为基础的ajax创建更具交互性的动态页面。 css：主要用于控制web页面的外观，而且能使页面的内容与其表现形式之间进行优雅地分离。 flash[2]：业界最常用的ria(rich internet applications)技术，能够在现阶段提供html等技术所无法提供的基于web的富应用，而且在用户体验[3]方面，非常不错。 silverlight：来自业界巨擎微软[4]的ria技术，虽然其现在市场占有率稍逊于flash，但由于其可以使用c#[5]来进行编程，所以对开发者非常友好。

5，什么是架构

架构一般指软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”【GS93】但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”【IEEE98】。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。一般而言，软件系统的架构（Architecture）有两个要素：·它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。详情参考http://baike.baidu.com/subview/190551/12477396.htm#viewPageContent

就是指物体的框架结构

6，三层架构和mvc模式有什么关系

三层架构和MVC是有明显区别的,MVC应该是展现模式(三个加起来以后才是三层架构中的UI层) 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。 1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。 2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。 3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。 MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的UI层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。mvc可以是三层中的一个表现层框架，属于表现层。三层和mvc可以共存。三层是基于业务逻辑来分的，而mvc是基于页面来分的。 MVC主要用于表现层，3层主要用于体系架构，3层一般是表现层、中间层、数据层，其中表现层又可以分成M、V、C，(Model View Controller)模型－视图－控制器曾把MVC模式和Web开发中的三层结构的概念混为一谈，直到今天才发现一直是我的理解错误。MVC模式是GUI界面开发的指导模式，基于表现层分离的思想把程序分为三大部分：Model-View-Controller，呈三角形结构。Model是指数据以及应用程序逻辑，View是指Model的视图，也就是用户界面。这两者都很好理解，关键点在于Controller的角色以及三者之间的关系。在MVC模式中，Controller和View同属于表现层，通常成对出现。Controller被设计为处理用户交互的逻辑。一个通常的误解是认为Controller负责处理View和Model的交互，而实际上View和Model之间是可以直接通信的。由于用户的交互通常会涉及到Model的改变和View的更新，所以这些可以认为是Controller的副作用。MVC是表现层的架构，MVC的Model实际上是ViewModel，即供View进行展示的数据。 ViewModel不包含业务逻辑，也不包含数据读取。而在N层架构中，一般还会有一个Model层，用来与数据库的表相对应，也就是所谓ORM中的O。这个Model可能是POCO，也可能是包含一些验证逻辑的实体类，一般也不包含数据读取。进行数据读取的是数据访问层。而作为UI层的MVC一般不直接操作数据访问层，中间会有一个业务逻辑层封装业务逻辑、调用数据访问层。UI层（Controller）通过业务逻辑层来得到数据（Model），并进行封装（ViewModel），然后选择相应的View。MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。 MVC如何工作 MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。视图V 视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services. 如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。模型M 模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。控制器C 控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。模型Model 模型是应用程序的主体部分。模型表示业务数据，或者业务逻辑. 实现具体的业务逻辑、状态管理的功能。视图View 视图是应用程序中用户界面相关的部分，是用户看到并与之交互的界面。就是与用户实现交互的页面，通常实现数据的输入和输出功能。控制器controller 控制器工作就是根据用户的输入，控制用户界面数据显示和更新model对象状态。起到控制整个业务流程的作用，实现View层跟Model层的协同工作。3层架构指:表现层(显示层) 业务逻辑层数据访问层(持久化)如果大家非要“生搬硬套”把它和MVC扯上关系话那我就只能在这里"强扭这个瓜"了即: V 3层架构中"表现层"aspx页面对应MVC中View(继承的类不一样) C 三层架构中"表现层"的aspx.cs页面(类)对应MVC中的Controller,理解这一点并不难，大家想一想我们以前写过的 Redirect，当然它本身就是跳转了一些链接页面，而MVC中的Controller要做的更爽，它控制并显示输出了一个视图。即然所起到的作用都是对业务流程和显示信息的控制，只不过是实现手段不同而已。 M 3层架构中业务逻辑层和数据访问层对应MVC中Model(必定View和Controller已找到“婆家”剩下Model只能是业务逻辑层和数据访问层了)为什么要使用 MVC 大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化(自PHP5.0版本后已全面支持面向对象模型)语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。首先，最重要的一点是多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Adobe Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松耦合的构件。对我来说，控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。拿一个简单的登陆模块说，需求是你输入一个用户名、密码，如果输入的跟预先定义好的一样，那么就进入到正确页面，如果不一样，就提示个错误信息“你Y别在这儿蒙我，输入的不对！”。 V 这个小小的模块中，起始的输入用户名密码的页面跟经过校验后显示的页面就相当于View C 而这里还需要一个controller页面，就是用于接收输入进来的用户名密码，还有经过校验后返回的一个flg（此flg就是用于判断你输入的是否正确，而跳转到相应的页面的） M 最后还缺一个Model，那么就是你那个用于校验的类了，他就是处理你输入的是否跟预先订好的一样不一样的，之后返回一个flg。这样就完全实现了逻辑跟页面的分离，我页面不管你咋整，反正我就一个显示，而controller呢也不管你Model咋判断对不对，反正我给你了用户名跟密码，你就得给我整回来一个flg来，而Medol呢，则是反正你敢给我个用户名跟密码，我就给你整过去个flgm 提供数据，数据之间的关系，转化等。并可以通知视图和控制器自己哪些地方发生了变化。 v 提供显示，能根据m的改变来更新自己 c 比如视图做了点击一个按钮，会先发给这个视图的控制器，然后这个控制器来决定做什么操作(让模型更新数据，控制视图改变) mvc是一个复合模式 mv，mc都是观察者模式 m内部的组件组合模式 vc之间是策略模式(可以随时更换不同的控制器)MVC模式是上世纪70年代提出，最初用于Smalltalk平台上的。 MVC是表现模式，是用来向用户展现的许多组建的一个模式（UI/Presentation Patten） MVC有三种角色： Model：用来储存数据的组件（与领域模型概念不同，两者会相互交叉） View：从Model中获取数据进行内容展示的组件。同样的Model在不同的View下可展示不同的效果。获取Model的状态，而不对其进行操作。 Controller：接受并处理用户指令（操作Model（业务）），选择一个View进行操作。MVC概述：协作存在单向引用，例如Model不知道View和Controller的存在。View不知道Controller的存在。这就隔离了表现和数据。View和controller是单向引用。而实际中View和Controller也是有数据交互的。MVC的重要特点是分离。两种分离： View和数据(Model)的分离使用不同的View对相同的数据进行展示；分离可视和不可视的组件，能够对Model进行独立测试。因为分离了可视组件减少了外部依赖利于测试。（数据库也是一种外部组件） View和表现逻辑(Controller)的分离 Controller是一个表现逻辑的组件，并非一个业务逻辑组件。MVC可以作为表现模式也可以作为建构模式，意味这Controller也可以是业务逻辑。分离逻辑和具体展示，能够对逻辑进行独立测试。MVC和三层架构 MVC与三层架构类似么？ View-UI Layer | Controller-Bussiness Layer | Model-Data Access Layer 其实这样是错误的 MVC是表现模式（Presentation Pattern）三层架构是典型的架构模式（Architecture Pattern）三层架构的分层模式是典型的上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系。即使将MVC当作架构模式，也不是分层模式。MVC和三层架构基本没有可比性，是应用于不同领域的技术。MVC模式与三层架构:ui (view)←(contorller)***********************bll (model) *********************** dal (model)

文章TAG：架构架构模式模式常用架构模式