社区
Web Services
帖子详情
三层架构WebService做中间层
foxriver1205
2009-12-26 09:37:59
本人在开发一个三层架构的网站,其中间层是使用WebService!现在碰到的问题是当你修改完某处代码之后,你的网站已经添加的WebService服务,你又得重新删除之后再添加一次,这样做导致效率极低。还有比如我的SQLServerDAL代码修改之后,而我在BLL中引用了SQLServerDAL.dll这个文件,我又得继续删除了这个dll文件在重新添加一次。。请教大虾们有何解决之道?
...全文
376
14
打赏
收藏
三层架构WebService做中间层
本人在开发一个三层架构的网站,其中间层是使用WebService!现在碰到的问题是当你修改完某处代码之后,你的网站已经添加的WebService服务,你又得重新删除之后再添加一次,这样做导致效率极低。还有比如我的SQLServerDAL代码修改之后,而我在BLL中引用了SQLServerDAL.dll这个文件,我又得继续删除了这个dll文件在重新添加一次。。请教大虾们有何解决之道?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
14 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
cuike519
2009-12-28
打赏
举报
回复
1、用WSDL引用,生成代理类的过程由VS或者工具自动完成。
2、用项目引用,被引用项目发生变化,程序集自动更新。
foxriver1205
2009-12-28
打赏
举报
回复
[Quote=引用 11 楼 yulinlover 的回复:]
我们的团队就是基本避免那种直接引用的方式,我记得我们的.net运行架构是用反射的方法结合远程调用的方式来实现所有中间层组件的调用的。没有遇到你说的这种情况。
你说的也许在VB里我们会经常遇到,那种组件互相引用,然后接口或者参数等变动导致组件不再兼容,这样会很痛苦。
[/Quote]
请问一下贵团队采取什么样的方式呢?
foxriver1205
2009-12-28
打赏
举报
回复
[Quote=引用 13 楼 cuike519 的回复:]
1、用WSDL引用,生成代理类的过程由VS或者工具自动完成。
2、用项目引用,被引用项目发生变化,程序集自动更新。
[/Quote]
这位大虾,请教一下何为项目引用?
yulinlover
2009-12-27
打赏
举报
回复
我们的团队就是基本避免那种直接引用的方式,我记得我们的.net运行架构是用反射的方法结合远程调用的方式来实现所有中间层组件的调用的。没有遇到你说的这种情况。
你说的也许在VB里我们会经常遇到,那种组件互相引用,然后接口或者参数等变动导致组件不再兼容,这样会很痛苦。
dingpo2099
2009-12-26
打赏
举报
回复
up
foxriver1205
2009-12-26
打赏
举报
回复
sp1234的一番语重心长,令我醍醐灌顶。。。 但是哥们能否分享一下经验你们团队是如何克服这种困难的。 1000个团队都使用了你发布的Service服务,当你这修改服务之后。。那1000个团队该怎么着呢?
foxriver1205
2009-12-26
打赏
举报
回复
[Quote=引用 5 楼 sp1234 的回复:]
引用楼主 foxriver1205 的回复:
本人在开发一个三层架构的网站,其中间层是使用WebService!现在碰到的问题是当你修改完某处代码之后,你的网站已经添加的WebService服务,你又得重新删除之后再添加一次,这样做导致效率极低。还有比如我的SQLServerDAL代码修改之后,而我在BLL中引用了SQLServerDAL.dll这个文件,我又得继续删除了这个dll文件在重新添加一次。。请教大虾们有何解决之道?
当你发布一个web service接口到网站(客户端使用了它的WSAL),那么你就有义务维护其稳定可用。你只能扩展,在扩展时维持其向下兼容性(这是因为xml在扩展时就可以向以前的版本兼容)。如果你在自己编程时感觉必须“重新删除添加一次”,可能是因为没有发布过大的产品,所以只在乎你自己开发时的那点用法而不在乎更具有历史性的东西。
至于第二点我看不懂你的意思。我想可能类似,你只是在用自己编程时遇到的一点现象来套用在别人在更广意义上的宣传吧。
[/Quote]
可能由于本人表达能力有限,导致各位大虾对我的这种情况出现误解,I'm sorry..
但是这个问题我想很多人都会遇到过。当你更改了某一层的代码或者新增了一个接口,而你在另外一层引用你刚刚作了修改的这一层。实际的操作既是添加了某个引用譬如:SQLServerDAL.dll。而你在BLL层添加了这个引用。。现在我的SQLServerDAL层作了修改。要怎么样才能实时更新到BLL层呢?求高手赐教。。
以专业开发人员为伍
2009-12-26
打赏
举报
回复
你在做两个以上团队之间协调才做的事情,却嫌团队要做的事情麻烦,这是自找麻烦的。有些人自己写个“三层结构”软件,硬要学别人分多少个目录甚至分几个工程,也是如此。不知道该不该如此,“反正别人这么做了我也这么做”,这就会嫌麻烦。除非你特意让自己克服这种嫌麻烦的心理。
团队开发之间就一定需要处理那种松散的关系。当开发一个服务的团队发布了新的服务,假设有20个团队使用到它(其实web service原本是为微软那种一个服务有10000个团队要使用的情况设计的),怎能强迫20个团队都去“删除、添加”呢?各个客户端系统中必然有同一服务的不同版本的存在,做服务软件的人必然要考虑这些。
如果你的系统架构不是恰好适合使用web service,那么为什么要使用web service?
以专业开发人员为伍
2009-12-26
打赏
举报
回复
客户端使用了它的WSAL --> 客户端使用了它的WSDL
以专业开发人员为伍
2009-12-26
打赏
举报
回复
[Quote=引用楼主 foxriver1205 的回复:]
本人在开发一个三层架构的网站,其中间层是使用WebService!现在碰到的问题是当你修改完某处代码之后,你的网站已经添加的WebService服务,你又得重新删除之后再添加一次,这样做导致效率极低。还有比如我的SQLServerDAL代码修改之后,而我在BLL中引用了SQLServerDAL.dll这个文件,我又得继续删除了这个dll文件在重新添加一次。。请教大虾们有何解决之道?
[/Quote]
当你发布一个web service接口到网站(客户端使用了它的WSAL),那么你就有义务维护其稳定可用。你只能扩展,在扩展时维持其向下兼容性(这是因为xml在扩展时就可以向以前的版本兼容)。如果你在自己编程时感觉必须“重新删除添加一次”,可能是因为没有发布过大的产品,所以只在乎你自己开发时的那点用法而不在乎更具有历史性的东西。
至于第二点我看不懂你的意思。我想可能类似,你只是在用自己编程时遇到的一点现象来套用在别人在更广意义上的宣传吧。
foxriver1205
2009-12-26
打赏
举报
回复
[Quote=引用 2 楼 yfqvip 的回复:]
第一个问题只能这么做的。
第二个问题可以通过修改dll的输出路径解决:
在类库上右击->属性->生成->将输出路径改到你的web层所在的文件下的bin的debug文件里。
把所有的dll的输出路径都改到这个地方,然后添加引用。
其实vs2005之后一般都会自动更新的,不过有时候好像不更新,反正你这么做了就不用频繁的重新添加了。
[/Quote]
我用的VS2008原本以为重新生成一下就可以了。。没想到这么滴......还有其他方法没?
wangan2008
2009-12-26
打赏
举报
回复
up
满衣兄
2009-12-26
打赏
举报
回复
第一个问题只能这么做的。
第二个问题可以通过修改dll的输出路径解决:
在类库上右击->属性->生成->将输出路径改到你的web层所在的文件下的bin的debug文件里。
把所有的dll的输出路径都改到这个地方,然后添加引用。
其实vs2005之后一般都会自动更新的,不过有时候好像不更新,反正你这么做了就不用频繁的重新添加了。
kingcsx666
2009-12-26
打赏
举报
回复
按理说直接刷新一下web引用,就会自动更新的
但是我的编辑器也不行……
ASP EXCEL导入SQL
我们今天以企业用户常用的CRM系统,来看一看标准的SaaSCRM应该是一个什么样子。 实际上,很多用户对于CRM并不陌生,早在2000年的时候,有一些企业就已经开始尝试CRM系统。在很多人眼中,CRM就是一套C/S或者B/S的应用系统。 而当CRM进入了SaaS,他在架构上会是一个什么样子呢?我们以361CRM为例,来看一下SaaSCRM的架构。 361CRM系统采用分布式架构。采用企业级的多层次、多应用的系统结构的SaaS在线CRM平台平台架构从大的层次上来分主要为四层,根据调用关系依次为应用层、缓冲层、服务层以及存储层,如下图所示: 应用层 从浏览器发送过来的请求,直接由应用层来进行直接响应; 平台是多租赁用户的在线多应用来实现的,由于每个用户的具体业务需求不同,因此每个租赁用户的应用是相互隔离的,但应用层的结构却都是相同,从上到下主要分为业务展现层、业务逻辑层、业务模型层、实体访问层; 业务展现层主要为用户数据的不同视图表现,为用户呈现各种易于浏览、便于理解的各种数据表现方式,如表单、表格、报表、图表等; 业务逻辑层主要是业务逻辑的具体实现层,对于用户动作、触发事件以及工作流程等由业务逻辑层来实现业务的处理以及响应,通过业务逻辑层对下层业务模型的访问来实现具体的逻辑处理; 业务模型层主要是业务对象的具体定义与封装,是对于现实中业务在平台中的最直接的映射; 实体访问层是对于业务逻辑层对于业务模型操作的封装,业务模型的实体状态的更新、删除、查询等都是通过实体访问层来实现。 缓冲层 缓冲层主要对于静态资源以及动态数据的缓存。静态资源主要是指应用层中展现层中所要使用到的静态资源文件,以及由用户在业务操作中产生的文件等,如图片、上传的文件等; 而动态数据是指用户在使用平台的过程中所产生的业务数据,在实现业务中,这部分数据大部分都是读操作比较多,而写操作比较少,因此可以针对这部分数据根据特定的缓存失效策略机制来进行相应的缓存; 缓冲层的缓存针对应用层是透明的,而且针对多应用也是透明的,因此缓冲层具有更大的弹性与灵活性。 服务层 服务主要是指平台的核心服务,核心服务分为业务共通服务以及平台共通服务,平台共通服务是指与业务无关且是平台最基础的服务,如任务调度、消息队列、邮件服务、图片处 理、工作流引擎等;而业务共通服务指基于平台共通服务,而对于所有业务具有共通性的服务,如日志审核、操作回滚、数据安全、全文检索、权限角色等; 服务层是对于平台运营、维护最核心的服务实现,是平台正常运行的基础。 存储层 存储主要分为两部分:分布式文件存储以及分布式的数据存储; 由于是多应用的平台,因此随着平台的运营,会产生海量的业务数据以及资源文件,因此伴随着海量的数据而来的问题就是存储、检索、分析以及统计等问题; 针对上述问题,361CRM平台采用了分布式的存储系统,基于Map-Reduce来进行相应的检索、分析以及统计,实现了对于海量数据的统一操作。 这种结构能
做
到真正的分布式网络计算,有效降低网络流量,减轻客户端负担,还能安全、方便地与互联网接口。另外公司员工或客户分布或行走于全国各地,通常都有移动办公需求。 REST 架构 REST是基于HTTP的,因此天生就有在互联网上穿透防火墙的能力,REST可以简单地认为它是轻量级的
WebService
,但是它具有自己的一些显著特点: 所有的资源通过统一的接口访问(HTTP/HTTPSGET、POST、PUT、ELETE),而且接口比较统一,便于与第三方的集成; 因为是基于HTTP/HTTPS的,因此可以将资源(响应)分为可缓存的和不可缓存的,以及采用浏览器的标准压缩方式,有效地提升网络效能。也可以在客户和资源之间插入不同的中间组件来提升性能和安全等,如,代理服务,缓存服务,网关服务等; 因为是基于HTTP/HTTPS的资源请求,因此本次连接和下一次到服务器的连接之间没有状态。由于361CRM平台采用了REST架构,因此也就决定了361CRM平台天然就具备以下几方面的优势: 由于REST本身无状态的特性,361CRM平台天然就是分布式的,决定了后台通过根据业务量而弹性地增加服务器就可以实现平台计算能力的线性增加; 所有的请求都是统一通过RESTAPI进行相应的资源与服务的请求,这样就能够保证系统提供的服务都是解耦的,极大的简化了系统,从而改善了系统的交互性和可重用性,同时也能够根据业务进行相应统一且透明的内存缓存 客户端浏览器能够轻松通过Ajax实现REST资源的异步调用处理,同时也可以有效地减少应用服务器地压力 通过提供开放的RESTAPI,能够轻松实现与第三方的集成 平台服务 平台服务层的调用是通过RESTAPI进行的,由于REST的特点,通过在URI中添加资源路径以及版本信息,很方便地能够实现平台的平滑升级以及数据兼容性问题。 平台服务层实现的都是共通的服务,服务之间是独立的,而且是插件式的方式来实现的,平台选用了面向分布式计算的Erlang语言来实现的,因此保证了这些插件式的服务能够热拔插地部署,实现真正地不宕机地部署与更新。 平台服务层的插件式架构,决定了平台的无限扩展能力,能够根据不断变化地用户需求而进行平台的不断地在线迭代与更新,与用户的需求形成一个良性的循环。配置定制平台通过服务器(Apache)的自定义开发,实现了企业用户应用的透明隔离,因此平台具有面向不同企业用户根据不同需求进行个性化定制的能力。不同的企业用户,一般主要有几方面的自定义需求:业务对象、工作流程、报表、布局等,而361CRM平台的平台框架就决定着能够很好地满足用户的自定义需求,主要分为以下几个方面: 由于用户使用的是文档数据库,有着松散的数据结构,因此用户根据需求,而可以随意自定义自己的业务对象; 361CRM平台后台的平台服务层,有相应的实时的工作流引擎,提供给用户强大的自定义工作流程功能; 361CRM平台有业内是丰富的报表模板,用户只需要根据自己的需要来选择即可,针对一些自定义的动态数据,还提供模板的再定义功能,能够很好地满足用户的报表需求; 由于平台是应用隔离的,因此针对着页面的布局,可以很容易地实现个性化地定制; 361CRM平台的配置功能的强大,并不以损失平台应用的易用性为基础,361CRM平台在操作上采用引导式操作,以及提供方便易用的在线帮助,大大地降低了系统使用的复杂度,使系统更加地人性化、简易化。 实时即时 361CRM平台的平台服务层与通常的应用服务不同,它是实时运行的服务,平台服务层有相应的任务调度机制,邮件服务、消息队列以及实时的工作流引擎等,这些服务都是实时运行的,因此当企业用户的业务对象或者业务流程发生变化时,通过这些平台服务就可以把即时的状态消息(通过邮件、短信或者其它的IM工具)推送给用户,让用户真正了解到业务的即时与实时的状态信息。 而通常的应用服务是静态的,只有当用户登录时,才会进行相应的业务状态的检查,这样就严重影响了业务处理的速度,对于即时性业务,就会带来很大的损失。 多级负载 平台是一个多租赁用户的在线SaaS系统,因此会给平台带来大量的高并发的请求,361CRM平台是一个多层次的结构,而且采用了REST架构,REST天生就是分布式,因此通过物理部署就可以实现高并发带的负载均衡。 四层负载在链路层解决来自互联网的并发请求压力,使用LVS+Heartbeat的主从双备的架构,保证不会出现单点故障; Web应用的大部分压力都来自于资源的请求,如图片,静态文件,样式表等文件的请求,服务器压力的70%都来自于这些资源的请求,因此对于这些静态资源的请求,通过静态资源缓冲层就能够很好解决这些请求对于后台造成的压力; 经过实测,经过一段时间稳定运行之后,静态资源缓冲层能够命中前台请求的80%以上,有效地缓解了应用服务器的压力; 七层负载层主要是
做
业务、以及资源的请求分流,把负载均衡到多台文件服务器以及应用服务器上; 文件服务器与应用服务器是分布式的,通过Map-Reduce进行任务的拆分与结果的合并,充分利用多台服务器的并行计算能力,提升整体平台的运行性能; 文件缓存采用多级缓存策略,解决命中率高的文件的频繁请求。而数据缓存则通过业务标签以及时效性策略进行数据的缓存,并且进行缓存的增量更新,有效地解决了对于后台的 数据读写压力; 分布式的存储系统有效地解决了海量数据的存储、检索、分析以及统计等问题。 可见,当传统的CRM系统转换为SaaS服务后,其架构方面还是发生了不少的变动的,也只有这样的变动,才使得CRM能够在SaaS平台上更好的为客户所服务。 附:什么是REST架构 REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术,同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网,这种网络将会使得搜索更加智能化。 REST与HTTP协议 REST软件架构是由RoyThomasFielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念,是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP,在实际中往往把REST理解为基于HTTP的REST软件架构,或者更进一步把REST和HTTP看作为等同的概念。 今天,HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议,而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位,而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现,才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导,才能避免在软件开发的实际工作过程中少走弯路。 REST与URI(资源定位) REST软件架构之所以是一个超媒体系统,是因为它可以把网络上所有资源进行唯一的定位,不管你的文件是图片、文件Word还是视频文件,也不管你的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。 REST与CRUD原则 REST软件架构遵循了CRUD原则,该原则告诉我们对于资源(包括网络资源)只需要四种行为:创建、获取(Read)、更新和销毁就可以完成对其操作和处理了。其实世界万物都是遵循这一规律:生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作:(生)、select(见)、(变)和(灭),所以有时候CRUD也写作为RUDI,其中的I就是,这四个操作是一种原子操作,即一种无法再分的操作,通过它们可以构造复杂的操作过程,正如数学上四则运算是数字的最基本的运算一样。 REST与网络服务 尽管在Java语言世界中网络服务目前是以SOAP技术为主,但是REST将是是网络服务的另一选择,并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议,而且也作为直接进行数据处理的工具。而当前的网络服务技术都需要使用其它手段来完成数据处理工作,它们完全独立于HTTP协议来进行的,这样增加了大量的复杂软件架构设计工作。REST的思想充分利用了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题:如何实现网络服务才能充分利用现有的HTTP协议?该问题给出了四个答案:去问微软;WSDL2.0/SOAP1.2;WS-Transfer;根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协议,而是一个聪明的会表现自己的协议,这也许是REST=RepresentationalStateTransfer的真正含义。 实际上目前很多大公司已经采用了REST技术作为网络服务,如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是ApacheCXF和Axis2.Java语言也制定关于REST网络服务规范:JAX-RS:JavaAPIforRESTful
WebService
s(JSR311)。相信还会出现更多与REST相关的激动人心的信息。 REST与AJAX技术 尽管AJAX技术的出现才不到两年时间,但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能,在一个企业内只要一个人下载了AJAX引擎,其它企业内部的人员,就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构,凡是采用AJAX技术的页面简洁而又丰富,一个页面表现了丰富多彩的形态。 AJAX技术还使用了一种不同于XML格式的JSON文件格式,这个意义在哪里呢?在REST软件架构下我们不能对于XML文件进行序列化处理,这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可,它被认为能以远比XML更好的方式来序列化和传输简单数据结构,而且它更简洁。这对REST是一个极大贡献和补充。 当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态,客户端的状态自己来管理,这是AJAX技术的应用之地。通过AJAX技术,可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。 REST与Rails框架 RubyonRails框架(简称Rails或者Rails框架)是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持,也是当今应用REST最成功的一个软件开发框架。Rails框架(从版本1.2.x起)成为了第一个引入REST作为核心思想的主流网络软件开发框架。在Rails框架的充分利用了REST软件架构之后,人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的支持。从最直观的角度看待REST,它是网络服务最理想的手段,但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃,让REST的思想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。 REST安全性 我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻,前者是一种传统的寄信方式,而后者是现代网络的电子邮件方式。要是是寄信和电子邮件都有病毒存在的话,传统的寄信被送到对方就很危险,而电子邮件是开发的,电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。这里并不是说明SOAP网络服务消息包含义病毒,而是说明HTTP是无法处理SOAP信息包究竟好不好,需要额外的软件工具解决这一问题,包括防火墙也用不上和管不了。 REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包,如你可以规定从外部来的只能读取(GET操作)自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证(BasicundDigestAuthentication)。除了这些REST自身的安全性功能外,还可以利用像基于信息的
WebService
sSecurity(JSR155)作为REST不错的补充。 我曾经遇到一个求职者,他的简历看起来不错,基本上没有大问题,但他就是没有收到任何回复。一天我半开玩笑似的问他是不是电话写错了,我一检查,果不其然。他改正后,立即收到了他所期望去的公司的面试电话。从这个故事中我们得到一点教训:哪怕只剩最后一秒钟,也要检查你的联系方式两遍。这是理所当然应该
做
到的细节,早
做
比晚
做
好。
三层架构
-服务器端:通用
WebService
数据交互中间件概述
网上搜索Delphi
三层架构
的服务器端开发,大部分的博文都详细阐述了如何使用DataSnap、Socket或者Dcom技术来时间与客户端的信息交互,大部分需要安装插件……虽然这种种方式能实现三层通讯,但是在跨语言通信方面似乎都没有招了。于是我们马上想到一个平台独立、低耦合的技术——
WebService
,畅想一下,如果我们的服务器端中间件能够支持Java、C#、Delphi等多种开发语言的客户...
Delphi XE7+
Webservice
三层架构
ERP系统简介
本文介绍了使用XE7+FileDAC+
WebService
技术方案搭建的
三层架构
的ERP系统案例展示,目前在畜牧业中使用,尤其适合中小型企业。
JavaWeb
三层架构
的理解/
三层架构
的优缺点/
三层架构
与MVC的区别
1、
三层架构
我们的开发架构一般都是基于两种形式,一种是C/S架构,也就是客户端/服务器,另一种是B/S架构,也就是浏览器服务器。在JavaEE开发中,几乎全都是基于B/S架构的开发。那么在B/S架构中,系统标准的
三层架构
从上至下分别包括:表现层、业务层、持久层。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。
三层架构
在我们的实际开发中使用的非常多。
三层架构
中,每一层各司其职,接下来我们就说说每层都负责哪些方面: 表现层: 表现层也称为界面层
架构-
三层架构
:
三层架构
顾名思义,
三层架构
分为三层,分别是“数据访问层”、“业务逻辑层”、“表示层”。数据访问层:数据访问层在作业过程中访问数据系统中的文件,实现对数据库中数据的读取保存操作。表示层:主要功能是显示数据和接受传输用户的数据,可以在为网站的系统运行提供交互式操作界面,表示层的应用方式比较常见,例如Windows窗体和Web页面。业务逻辑层:将用户的输入信息进行甄别处理,分别保存。建立新的数据存储方式,在存储过程中对数据进行读取,将“商业逻辑”描述代码进行包含。
三层架构
软件系统。
Web Services
12,162
社区成员
16,328
社区内容
发帖
与我相关
我的任务
Web Services
.NET技术 Web Services
复制链接
扫一扫
分享
社区描述
.NET技术 Web Services
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章