JavaEE软件三层结构和MVC的区别
1、Model(业务模型):应用程序中用于处理应用程序数据逻辑的部分,通常模型对象负责在数据库中存取数据。
说白了就是确定要打的地基等一系列信息的。
2、view(视图):应用程序中处理数据显示的部分。
通常视图是依据模型数据创建的。
其实就是反映了盖出来的到底是楼还是房。
3、controller(控制器):应用程序中处理用户交互的部分。
通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。
其实就是决定收集到到底是开发商要来盖楼盘还是个体户要来盖房子
什么是工厂模式三层结构
工厂模式包含简单工厂,抽象工厂和工厂模式三类,工厂模式提供创建对象的接口,是属于创建型的模式三层结构一般指表示层(UI),业务逻辑层(BLL),数据访问层(DAL) ,降低各层之间的耦合,使项目结构更清楚,分工更明确,有利于后期的维护和升级
C#中的三层结构是什么?具体的感念和作用?
一、什么是三层结构在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。
微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层.二、三层结构的优点1、开发人员可以只关注整个结构中的其中某一层;2、可以很容易的用新的实现来替换原有层次的实现;3、可以降低层与层之间的依赖;4、有利于标准化;5、利于各层逻辑的复用。
概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。
一个好的分层式结构,可以使得开发人员的分工更加明确。
一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。
例如UI人员只需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。
每个开发人员的任务得到了确认,开发进度就可以迅速的提高。
松散耦合的好处是显而易见的。
如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依赖,谁都是不可替换的。
一旦发生改变,则牵一发而动全身,对项目的影响极为严重。
降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。
每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。
进行好的分层式结构设计,标准也是必不可少的。
只有在一定程度的标准化基础上,这个系统才是可扩展的,可替换的。
而层与层之间的通信也必然保证了接口的标准化。
三、分层式结构缺陷:1、降低了系统的性能。
这是不言而喻的。
如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在自上而下的方向。
如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
转(http://zhidao.baidu.com/question/76991818.html)
三层架构和MVC什么关系?如何理解?
ABAP的三层架构,三层架构是一个综合软件和硬件的概念。
最底层:数据层-DATABASE layer ABAP的数据库不仅仅存储数据,还存储了ABAP的所有程序。
这一点是与其他语言不同的。
当然了,程序代码和数据库表不是存储在一起的,是要在ABAP的数据层分开处理的。
中间层:应用层-APPLICATION layer ABAP的应用层相当于一个分布式的服务提供中心,对系统用户的请求进行分布式最优化的响应。
处理业务逻辑,响应客户请求等等。
中间层会从最底层数据层中将系统访问用户要访问的程序和数据取出来,放置到中间层的缓存当中,当业务处理完毕后,再把所有取出来的程序和数据放回去。
最高层:表现层-PRESENTATION layer ABAP的表现层就是用户访问ABAP系统能够看到的界面。
程序员编程界面、用户登录操作查询界面就在这一层上了。
包括程序代码,程序界面,程序运行结果等等。
因为我对MVC的理解不是很深刻,对于其概念描述实在是看不懂,所以难以作出客观的比较,希望得到大家的指点。
M就是MODULE吧,是不是就是这个系统的整个框架与模型呢?V就是VIEW吧,也就是系统的外在表现吧,应该与ABAP的表现层类似吧,除了ABAP的表现层还包含了程序员开发程序的界面。
C就是CONTROL吧,就是处理业务逻辑对吧,就是控制系统功能吧,应该与ABAP的中间层应用层有所类似吧?
三层架构体系的应用范围
C/S (Client/Server)结构,即大家熟知的客户机和服务器结构。
它是软件系统体系结构,通过它可以充分利用两端硬件环境的优势,将任务合理分配到Client端和Server端来实现,降低了系统的通讯开销。
目前大多数应用软件系统都是Client/Server形式的两层结构,由于现在的软件应用系统正在向分布式的Web应用发展,Web和Client/Server 应用都可以进行同样的业务处理,应用不同的模块共享逻辑组件;因此,内部的和外部的用户都可以访问新的和现有的应用系统,通过现有应用系统中的逻辑可以扩展出新的应用系统。
这也就是目前应用系统的发展方向。
Java Web 开发时的 MVC 模型和软件的3层架构(表现层,业务逻辑...
朋友您好!首先,MVC和三层架构,是不一样的。
三层架构中,DAL(数据访问层)、BLL(业务逻辑层)、WEB层各司其职,意在职责分离。
MVC是 Model-View-Controller,严格说这三个加起来以后才是三层架构中的WEB层,也就是说,MVC把三层架构中的WEB层再度进行了分化,分成了控制器、视图、实体三个部分,控制器完成页面逻辑,通过实体来与界面层完成通话;而C层直接与三层中的BLL进行对话。
所以, .net的三层结构中,并没有action这个概念。
asp.net mvc 是微软新发布的一种网站开发架构。
为了解决传统asp.net开发中不能分离Model,View和Controller而设计的。
普通的网站为了解决可移植,可维护,可扩展等问题,会把网站设计成三个独立的模块,Model负责数据库部分,View负责网页的界面,而Controller负责界面与数据的交互及业务逻辑,这样设计的网站如果想设计或者重新开发某一个模块对其他的模块是没有影响的。
但是asp.net的页面后台代码与每个页面代码都是一一对应的,业务逻辑在某些情况下不可避免的被写到了与View关联的后台代码中。
这样就不能保证View与Controller的分离,也就很难实现网站的重写和升级。
而在MVC中页面代码并不是与后台代码一一对应,而是分别被存放成Controller和View两个部分,彻底的解决了,View和Controller不能独立的问题。
从而改善网站的重写和升级过程。
但是MVC也有其缺点,由于在页面代码中不再可以使用服务器控件,因此给某些asp.net服务器端控件的使用带来了麻烦,而且MVC也页面的设计工作带来了很多障碍。
ASP.NET MVC 是微软在2009年4月份发布的一种新的网站开发架构,http://msdn.microsoft.com/en-us/library/dd394709.aspx,它是把传统意义上的MVC开发思想融合到了ASP.NET的开发当中。
那么我也来讲讲我对这两者的理解吧。
首先对这个题目,本身是存在问题的,“XX结构”与“XX模式”的区别?请问中国社会制度与美国人生活方式有什么区别? 这两者本身讲的是不同方向与角度的问题,在实际应用中他们的确存在一些相似的特点,在很多书籍中也没有深入讲解,以致于造成困惑,为了更好的理解他们,姑且来说说区别吧。
首先N层结构是一种软件抽象的层次结构,是对复杂软件的一种纵向切分,每一层次中完成同一类型的操作,以便将各种代码以其完成的使命作为依据来分割,以将低软件的复杂度,提高其可维护性。
一般来说,层次之间是向下依赖的,下层代码未确定其接口(契约)前,上层代码是无法开发的,下层代码接口(契约)的变化将使上层的代码一起变化。
三层结构是N层结构的一种,是人产在长时间使用中得出来的一种应用场合广泛的N层结构,被当作一种典型的软件层次结构而广为流传甚至写入教科书。
MVC模式是一种复合设计模式,一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。
巧合的是他也有三个事物组成,于是乎人们就有了一种想当然的对应关系:展示层-View;业务逻辑层-Control;持久层-Model。
首先MVC中的三个事物之间并不存在明显的层次结构,没有明显的向下依赖关系,相反的,View和Model往往是比较独立的,而Control是连接两者的桥梁,他们更像是横向的切分。
这样一来就出现一个结果,MVC中每个块都是可以独立测试的,而三层结构中,上层模块的运行测试势必要提供下层代码或者提供相同接口的桩。
相对来说,MVC复杂得多,但是结构更清晰,耦合性更低。
另外,MVC中每一块内部特别是Model内部经常被设计为多层的。
在我认为的一个良好的MVC模式构建的结构中,Control是核心,小且较为稳定的,可以作为一个核心框架来提供,有扩展点,但基本上可以简单配置不需要任何代码就可以运行。
而View则可能是一套或多种可选择的视图引擎,决定了软件展示给用于的界面,使用时的主要工作量在于扩展点以及根据需要而数量不同的视图模板。
Model则是业务提供者,决定了软件提供的功能,其内部可能是一些普通的类或者是实现了某些接口的类,在这一块当中可能根据业务的不同而色彩缤纷,对于复杂的软件可能会分成很多层,如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。
我经常用于比喻MVC的例子是小时候玩的那种卡带式游戏机,Control是主机,一般来说我买一个主机就行了,只要他不坏,他就能一直让我玩这一类的游戏。
View则是电视机和游戏手柄,电视机可以独立工作,他不管输入的是电视信号、影碟机信号还是游戏机信号,他只管显示,而且他决定了我们看到的效果是怎么样的,如果我想要个尺寸更大的或者彩色的显示效果,我只需要买个相应的电视机就行了,手柄也是可以换的,要遥杆还是带震动的。
Model则是游戏卡带,他绝定了我玩的是什么游戏,是魂斗罗还是超级玛莉,而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。
卡带中可能会有游戏代码和存储单元,都根据游戏的需要而设计。
有朋友提到游戏主机提供的卡带插槽的接口,在设计中,有时也由Control提供一组接口,以用于Model或View的实现,...