J2EE表现层设计思考核心
J2EE表现层设计思考核心是什么?下面yjbys小编为大家分享最新J2EE表现层设计解读,希望对大家学习J2EE有所帮助!
设计表现层时需要考虑的几个问题
开发者在设计表现层时,可以使用不同的模型,这时需要考虑一些相关的设计问题。这些问题和模型关系的紧密程度也各有不同,它们可以影响系统的各个方面,包括有安全、数据完整性、可管理性和扩展性。虽然这些设计问题大部分都可以用模型的形式表示,但我们不打算这样做,因为这样更为抽象,我们选择以非正式的文档形式表示。我们只是根据不同的模型,将每个需要考虑的问题列出来。
Session管理
用户Session指的是跨越一个客户和服务器多个请求间的一个对话。我们将在以下部分根据用户Session的概念讨论这个问题。
客户端的Session状态
在客户端保存Session的状态指的是将Session的状态串行化并且嵌入到返回给客户的HTML页面中。
在客户端保存Session的状态有这以下的好处:
. 它实现起来相对容易
. 在保存少量的状态信息时,它工作得很好
此外,这个策略还消除了跨越多个服务器复制状态的问题,例如多个服务器间实现负载均衡时就会遇到这种情况。
在客户端保存Session状态通常有两个方法HTML的隐藏字段和HTTP cookies我们将在下面讨论这些策略。第三个策略则是在每个页面的URL中嵌入Session状态信息。
虽然第三个方法比较少见,但它也有着其它两个方法的许多限制。
HTML的隐藏字段(HTML Hidden Fields)
虽然这个方法实现起来相对容易,不过使用HTML隐藏字段在客户端保存Session状态仍然有着许多的缺点。这些缺点在保存大量的状态时尤为突出。保存大量的状态将会对性能有很大的影响。因为每次发出请求和响应时,都需要在网络中传送这些状态信息。
此外,当你利用隐藏的字段来保存Session状态时,这些持久的状态值只能是字符串值,因此所有的对象引用都必须被“字符串化”,而这些信息除非经过特别的加密,否则都是以明文的形式显示在HTML的源代码中。
HTTP Cookies
与隐藏字段的方法一样,使用HTTP Cookies的方式也是相对简单的。不幸的是,这两个方法有着许多相同的缺点。特别是,在保存大量的状态信息时将会对性能产生很大的影响,因为在每次的请求和响应时,都必须在网络上传送全部的Session状态信息。
在客户端保存Session状态时,我们也会遇到大小和类型的局限问题。cookie headers的大小是有限制的,这样就限制了可以被持久保存的数据量,而且和隐藏字段的方法一样,当你使用cookies来保存Session状态时,这些持久的状态信息只能使用字符串值。
在客户端保存Session状态会带来的安全问题
当你在客户端保存Session状态时,你必须考虑到由此带来的安全问题。如果你不想数据暴露给客户端,你就需要一些方法来加密数据,从而保证数据的安全。
虽然在客户端保存Session状态相对容易实现,不过它有着很多的缺点,这些都要我们花费时间去解决。对于需要处理大量数据的项目,特别是企业的系统,使用这种方式是得不偿失的。
表现层的Session状态
当Session状态保存在服务器端时,它使用一个Session ID得到,并且会一直保持住,直到发生以下的情形:
. 一个预定义的Session超时发生了
. Session被手动设置为无效
. 状态由Session中移除
要注意的是服务器关闭后,一些内存中的Session管理机制可能不能恢复。
很明显,对于要保存大量Session状态的应用,将它们的Session状态放在服务器是更好的。当状态被保存在服务器上时,你不会有客户端Session管理的大小和类型限制。此外,还避免了由此带来的安全问题,而且也不会遇到由于在每个请求间传送Session状态带来的性能影响。
使用该方式,你可以更加灵活地作处理,并且便于扩展和提高性能。
如果你在服务器上保存Session状态,你必须要决定如何使该状态信息被每个服务器得到,即你运行该应用的服务器。如果群集的软件是运行在负载均衡的硬件上,那么就要处理这个Session状态的复制问题,这是一个多维的问题,不过,众多的应用服务器现在都提供了各种各样的解决方案。也就是说,在应用服务器的级别上有解决的方法。其中的一个方法是保证用户只与一个服务器打交道,它在流量管理软件上用得比较多,例如Resonate [Resonate]的软件,在用户的Session中,该用户发出的每个请求都会被路由到同一个服务器处理。这种方式也被称为server affinity。
另一个可选的方式是在商业层或者资源层保存Session状态。企业JavaBeans组件可用来在商业层保存Session的状态,而一个关系数据库则可用在资源层。
控制客户
有很多时候我们都要限制或者控制客户端某些应用资源。下面我们就来讨论其中两种这样的情形。
限制或者控制客户的一个原因是防止一个视图或者部分的视图被一个客户直接。这个问题会发生在以下情况,例如仅有注册或者登陆后的用户才可允许一个特别的视图,或者是根据用户的角色限制用户部分的视图。
在描述过这个问题后,我们将讨论第二种情况,它和控制应用中一个用户的流程有关。后者的讨论和重复的form提交有关,因为多次提交将会导致不必要的重复事务。
控制视图
在一些情况下,资源被限制为完全不允许某些用户。有几个方法可以做到这一点。一个方法是加入应用逻辑到处理控制器或者视图的程序中,禁止某些用户。另一个方案是设置运行时的系统,对于一些资源,仅允许经由另一个应用资源内部调用。在这种情形,对于这些资源的必须被通过另一个表现层的应用资源进行,例如一个servlet控制器。对于这些受限制的资源不允许通过一个浏览器直接调用。
处理这个问题的一个常见方法是使用一个控制器来作为该类控制的一个委托者。另一个常见的方式是在一个视图中置入一个保护设置。我们这里主要讨论基于视图的控制策略。在考虑选择何种方式来控制之前,我们首先来描述一下这些策略。
在视图中置入保护逻辑
对于在一个视图的处理中置入一个保护逻辑,有两个常见的应用。一个是防止整个的资源,而另一个是限制部分的资源。
在每个视图中包含一个All-or-Nothing保护
在一些情况下,置入到视图处理代码中的逻辑以all-or-nothing的模式允许或者拒绝。也就是说,这个逻辑限制某个特别的用户一个特别的视图。通常这一类型的保护最好封装到一个中央化的控制器中,这样便于集中化管理。如果只有很少的页面需要防护,那么可以使用这个策略。通常这个情形都是发生在一个非技术人员需要更新网站一小部分的静态文件。如果客户仍然需要登陆到网站来浏览这些页面,那么只需要在每个页面的顶部加入一个自定义的tag(标记)就可以做到控制。如3.1的例子所示。
例子3.1 在每个视图中包含一个All-or-Nothing保护
<%@ taglib uri="/WEB-INF/" prefix="corePatterns" %> <corePatterns:guard/> <HTML> . . . </HTML>给视图的某些部分加入保护
在其它情况下,置入到视图处理代码的逻辑可拒绝一个视图的某些部分。这个策略可以和上面的all-or-nothing策略一起使用。为说明这一点,我们这里使用控制一个建筑物中的一个房间作类比。all-or-nothing的`保护策略告诉用户是否可以进入房间,而第二个保护策略则是告诉用户在进入房间后,允许他们看到什么东西。以下就是一些你可以利用这个策略的例子。
根据用户的角色决定是否显示视图的某些部分
根据用户的角色,视图的某部分可能不显示。例如,一个经理在收看管理信息时,他可以到其员工的子视图,而作为一个员工,他只可以看到自己组织的信息,而不可以其它信息,如例子3.2所示。
例子3.2 根据用户的角色,部分的视图不显示
<%@ taglib uri="/WEB-INF/" prefix="corePatterns" %> <HTML> <corePatterns:guard role="manager"> <b>This should be seen only by managers!</b> <corePatterns:guard/> </HTML>This should be seen only by managers!
根据系统的状态或者错误情形不显示部分的视图
根据系统的环境,显示的规划可以被修改。例如,如果用户使用的是一个单CPU的硬件设备,那么使用多个CPU的部分设备就可以不显示。
根据配置控制资源
要限制某个客户直接一个特别的视图,你可以配置表现层只有通过内部的资源才可以到这些资源,例如一个使用RequestDispatcher的servlet控制器。此外,你还可以使用Web容器中内置
的安全技术,根据servlet2.2或者以后的规范。安全限制被定义在称为的配置描述文件中(deployment descriptor)。
basic和form-based的认证方法在Servlet规范中也有描述。在此我们不打算重复这个规范,你可以到以下网址去查看当前规范的细节()。
你已经明白了加入安全限制到你的应用时会有什么用处,我们简要讨论了这个问题并且介绍了如何通过配置令它和all-or-nothing保护相关。最后,我们描述了一个简单和常用的方法作为all-or-nothing保护,以限制一个资源的。
通过安全限制保护资源
应用或许被配置在一个安全限制中,而这个安全限制允许使用编程的方法根据用户的角色来控制。资源可以被某些角色的用户,并且禁止其它的角色。另外,某个视图的一部分也可以根据用户的角色来限制。
相關文章
-
J2EE当前持久层设计常见问题
当前J2EE项目中,面临的一个共同问题就是如果控制事务的并发访问,虽然有些持久层框架已经为我们做了很多工作,但是理解原理,对于我们开发来说还是很有用处的。下面小编为大家整理了J2EE当前持久层设计的常见问题,一起来看看 -
J2EE核心技术
为了联系实际,GOULD基于WEBLOGIC应用服务器(来自BEASYSTEMS公司的一种广为应用的产品)环境来介绍J2EE的这些技术。JAVA最初是在浏览器和客户端机器中闪亮登场的。当时,很多人质疑它是否适合做服务器端的开发。随着对JAV -
J2EE应用的核心策略
对于J2EE,我们知道当开发应用时,在架构设计阶段的决定将对应用的性能和可扩展性产生深远的影响。现在当开发一个应用项目时,我们越来越多地注意到了性能和可扩展性的问题。应用性能的问题比应用功能的不丰富问题往往更为 -
J2EE的13种核心技术
J2EE(Java 2 Platform, Enterprise Edition)是一个为大企业主机级的计算类型而设计的Java平台。Sun微系统(与其工业伙伴一起,例如IBM)设计了J2EE,以此来简化在瘦客户级环境下的应用开发。下面是小编整理的关于J2EE的13 -
J2EE的13种核心技术简介
Java最初是在浏览器和客户端机器中粉墨登场的。当时,很多人质疑它是否适合做服务器端的开发。下面是小编整理的关于J2EE的13种核心技术简介,希望大家认真阅读!随着对Java2平台企业版(J2EE)第三方支持的增多,Java被广泛接 -
折叠J2EE的核心API与组件积累
大学四年里,我一直从各方面不断努力,提升自己多方面的能力。学习上认真刻苦,成绩名列前茅。多次荣获奖学金及优秀学生称号。在学好专业课的同时,我还在课余时间学习了计算机c语言。外语方面我的成绩也在年级前列。并在xx -
J2EE的层次和组成
J2EE组件和“标准的” Java类的不同点在于:它被装配在一个J2EE应用中,具有固定的格式并遵守J2EE规范,由J2EE服务器对其进行管理。以下是关于J2EE的层次和组成,欢迎大家参考!目前,Java 2平台有3个版本,它们是适用于小型设备 -
J2EE架构与设计培训
一个人的信仰是一生的追求和行为的准则。方永刚说:没有科学信仰的人是不幸的人,我的信仰就是马克思主义; 我们做马克思主义理论教员的,自己都不坚信真理的话,怎么让别人相信呢?自己都不感动的话,又怎么去感动别人?方永刚追 -
J2EE分层服务器部署方法
J2EE是使用Java技术开发企业级应用的工业标准,它是Java技术不断适应和促进企业级应用过程中的产物。适用于企业级应用的J2EE,提供一个平立的、可移植的、多用户的、安全的和基于标准的企业级平台,从而简化企业应用的开发 -
J2EE设计模式图书目录
前言第一章 Java企业设计第二章 统一建模语言第三章 表达层体系结构第四章 高级表达层设计第五章 表达层可伸缩性第六章 业务层第七章 层通信第八章 数据库和数据模式第九章 业务层接口第十章 企业并发第十一章 消息