上下文的哲学思考

1 上下文的哲学思考

上下文是英文context的中文译法。“在线新华字典”对上下文的解释是“文章中与某一文句相连的前文和后文”。

“百度百科”对上下文的解释是“一种属性的有序序列，它们为驻留在环境内的对象定义环境。在对象的激活过程中创建上下文，对象被配置为要求某些自动服务，如同步、事务、实时激活、安全性等等。多个对象可以存留在一个上下文内。也有根据上下文理解意思的意思。”。

网上一些网友对上下文的认识，我们常说听话传话不能“断章取义”，而要联系它的“上下文”来看。比如，小丽对王老五说“我爱你”，光看这句还以为在说情话呢。但一看上下文－－“虽然我爱你，但你太穷了，我们还是分手吧”，味道就完全变了。从这里来看“上下文”也有“环境”的意思，就是语言的环境。

从上述的三种定义或解释来看，上下文也就是我们平常所说的语境。“语境（context）是人们在交际活动中的各种语言环境，也叫言语环境。语境的构成有客观因素和主观因素。时间、地点、场合、对象是客观因素。说话者的身份、职业、思想、修养以及处境、心情等是主观因素。”

上下文是一个记录一个系统在过去、当前、未来所依赖的环境以及所在环境发生事项的一个记录区，其作用是当某个行为发生时可以在访记录区中查找该行为执行时所依据的前置条件和后置条件（上文即前置条件，下文即后置条件），确保行为能正确执行。

上下文研究的是一个时段内，多个主体、对象在历次操作活动时，在空间的信息投射。因为在时段的时点上需要依赖前一个时点的信息，所以需要上下文来记录时段内的信息。

2 程序中的上下文

2.1 JNDI的一个类javax.naming.InitialContext

它读取JNDI的一些配置信息，并内含对象和其在JNDI中的注册名称的映射信息。请看下面的代码

InitialContext ic=new InitialContext();

RMIAdaptor server=(RMIAdaptor)ic.lookup("jmx/invoker/RMIAdaptor");

这是一段JBoss中获取MBean的远程调用类的代码。在这里面通过InitialContext中JNDI注册的名称“jmx/invoker/RMIAdaptor”来获得RMIAdaptor

对象。这和JAVA集合中的MAP有点象，有一个String的key，key对映着它的对象。

2.2 Spring中ApplicationContext

Spring中最常见的几句代码。ApplicationContext 是内含configuration.xml配置文件的信息，使得可以通过getBean用名称得到相应的注册对象。

ApplicationContext ctx= new FileSystemXmlApplicationContext("configuration.xml");

Object obj= ctx.getBean("Object_Name");

2.3 上下文的总结

从上面的代码，可以体会到Context所代表的意义：公用信息、环境、容器....。所以我觉得Context翻译成上下文并不直观，按照语言使用的环境，翻译成“环境”、“容器”可能更好。

3 Web程序中的上下文

3.1 客户端上下文Cookie

Cookie 为 Web 应用程序保存用户相关信息提供了一种有用的方法。例如，当用户访问站点时，可以利用 Cookie 保存用户首选项或其他信息，这样，当用户下次再访问站点时，应用程序就可以检索以前保存的信息。所以cookie是用户通过浏览器与应用程序间进行交互时部分信息的上下文存贮空间。

Cookie是一个在客户端保存有用户访问网站信息的数据存贮文件。（如果你安装的是XP，可以看一下<安装Windows的盘>:/Documents and Settings/<用户名>/Cookies文件夹）。用户访问网站的时候，网站会给用户一个包含过期时间的Cookie，浏览器收到 Cookie后就存放在客户端的文件夹下。以后用户每次访问网站页面的时候，浏览器会根据网站的URL在本地Cookie文件夹内查找是否存在当前网站关联的Cookie，如果有的话就连同页面请求一起发送到服务器。

关于Cookie的知识还需要了解以下几点。

(1) Cookie只是一段字符串，是一个信息文件，是由浏览器调用执行的。

(2) 大多数浏览器规定Cookie大小不超过4K，每个站点能保存的Cookie不超过20个，所有站点保存的Cookie总和不超过300个。

(3) 除了Cookie外，几乎没有其他的方法在客户端的机器上写入数据（就连Cookie的写入操作也是浏览器进行的）。当然，连Cookie都可以通过浏览器安全配置来禁止。如果你使用IE浏览器，可以看一下“工具”→“Internet”选项→“隐私”一页。现在的大多数网站都利用Cookie来保存一些数据（比如你的ID），以便你下一次访问网站时能直接“继续”以前的配置，所以我还是建议你不要轻易关闭Cookie。

(4) 在使用Cookie时，必须意识到其固有的安全弱点。Cookie毕竟是存放于客户端的。因此，不要在Cookie中保存保密信息，如用户名、密码、信用卡号等。在Cookie中不要保存不应该由用户掌握的内容，也不要保存可能被其他窃取Cookie的人控制的内容。

3.1.1 Cookie的创建和删除

3.1.1.1 客户端程序

如何保存、读取、删除和修改Cookie。首先在页面上添加4个按钮用来完成这4个操作。

<asp:Button ID="btn_SaveCookie" runat="server" nClick="btn_SaveCookie_Click"

Text="保存Cookie" />

<asp:Button ID="btn_ReadCookie" runat="server" Text="读取Cookie"

OnClick="btn_ReadCookie_Click" />

<asp:Button ID="btn_ModifyCookie" runat="server" OnClick="btn_ModifyCookie_Click" Text="修改Cookie" />

<asp:Button ID="btn_DelCookie" runat="server" Text="删除Cookie"

OnClick="btn_DelCookie_Click" />

3.1.1.2 服务端程序

(1) 保存Cookie的方法

protected void btn_SaveCookie_Click(object sender, EventArgs e)

{

HttpCookie SingleValueCookie = new HttpCookie("test1", "单值Cookie");

SingleValueCookie.Expires = DateTime.Now.AddDays(1);

Response.Cookies.Add(SingleValueCookie);

HttpCookie MultiValueCookie = new HttpCookie("test2");

MultiValueCookie.Values.Add("key1", "value1");

MultiValueCookie.Values.Add("key2", "value2");

MultiValueCookie.Expires = DateTime.Now.AddDays(1);

Response.Cookies.Add(MultiValueCookie);

}

我们可以看到，一个Cookie中允许保存单个值也可以保存多个值。HttpCookie类型表示一个Cookie，Expires属性用于修改 Cookie的过期时间。对于单值Cookie，既可以直接在构造方法中指定值也可以使用Value属性指定值。对于多值Cookie，既可以使用 Values属性的Add方法添加子键和值，也可以直接使用Values属性的索引设置子键和值。上面这段代码等价于下面这段代码。

(2) 读取Cookie的方法

protected void btn_ReadCookie_Click(object sender, EventArgs e)

{

HttpCookie SingleValueCookie = Request.Cookies["test1"];

if (SingleValueCookie != null)

{

Response.Write(string.Format("Key:{0} Value:{1} Expires:{2}<br/>", "test1",

SingleValueCookie.Value, SingleValueCookie.Expires));

}

HttpCookie MultiValueCookie = Request.Cookies["test2"];

if (MultiValueCookie!= null)

{

Response.Write(string.Format("Key:{0} Value:{1}<br/>", "test2", MultiValueCookie.

Value));

foreach (string subkey in MultiValueCookie.Values.AllKeys)

{

Response.Write(string.Format("SubKey:{0} Value:{1} Expires:{2}<br/>",

subkey, MultiValueCookie.Values[subkey], MultiValueCookie.Expires));

}

}

}

对于多值Cookie，我们通过遍历AllKeys属性返回的字符串数组获取所有子键Key，从而获得子键的值。要注意的是，在访问Cookie以前，需要检测一下Cookie是否存在。打开页面，先单击“保存Cookie”按钮，然后单击“读取Cookie”按钮，得到以下输出：

Key:test1 Value:单值Cookie Expires:0001-1-1 0:00:00

Key:test2 Value:key1=value1&key2=value2

SubKey:key1 Value:value1 Expires:0001-1-1 0:00:00

SubKey:key2 Value:value2 Expires:0001-1-1 0:00:00

(3) 删除Cookie的方法

protected void btn_DelCookie_Click(object sender, EventArgs e)

{

HttpCookie SingleValueCookie = Request.Cookies["test1"];

SingleValueCookie.Expires = DateTime.MinValue;

Response.Cookies.Add(SingleValueCookie);

}

我们始终要记住，服务器不能直接删除Cookie，删除Cookie的操作是浏览器进行的。说是删除，其实是把它的过期时间设置为过去的时间，让Cookie过期。因此，对于删除操作来说有三个步骤。

1．从Request对象中获取Cookie。

2．把Cookie的过期时间设置为过去的时间。

3．把Cookie重新写回Response中。

(4) 修改Cookie的方法

protected void btn_ModifyCookie_Click(object sender, EventArgs e)

{

HttpCookie SingleValueCookie = Request.Cookies["test1"];

SingleValueCookie.Value = "修改后的单值Cookie";

Response.Cookies.Add(SingleValueCookie);

}

3.1.2 Cookie的应用总结

Cookie虽然是一个简单实用的对象，但是我们也要注意Cookie的工作原理、大小限制以及安全性等，大致可以归纳为以下几点。

(1) 存储的物理位置。客户端的Cookies文件夹内;

(2) 存储的类型限制。字符串;

(3) 状态使用的范围。当前请求上下文的上下文都能访问到Cookie，Cookie对每个用户来说都是独立的;

(4) 存储的大小限制。每个Cookie不超过4K数据。每个网站不超过20个Cookie。所有网站的Cookie总和不超过300个;

(5) 生命周期。每个Cookie都有自己的过期时间，超过了过期时间后失效;

(6) 安全与性能。存储在客户端，安全性差。对于敏感数据建议加密后存储;

(7) 优点缺点与注意事项。可以很方便地关联网站和用户，长久保存用户设置;

3.2 服务端每用户上下文Session

Session又称为会话状态，是Web系统中最常用的状态，用于维护和当前浏览器实例相关的一些信息。举个例子来说，我们可以把已登录用户的用户名放在Session中，这样就能通过判断Session中的某个Key来判断用户是否登录，如果登录的话用户名又是多少。我们知道，Session对于每一个客户端（或者说浏览器实例）是“人手一份”，用户首次与Web服务器建立连接的时候，服务器会给用户分发一个SessionID作为标识。SessionID 是一个由24个字符组成的随机字符串。

用户每次提交页面，浏览器都会把这个SessionID包含在HTTP头中提交给Web服务器，这样Web服务器就能区分当前请求页面的是哪一个客户端。那么，ASP.NET 2.0提供了哪些存储SessionID的模式呢：

(1) Cookie（默认）：如果客户端禁止了Cookie的使用，Session也将失效。

(2) URL：Cookie是否开启不影响Session使用，缺点是不能再使用绝对链接了。

前面说了SessionID可以存储在客户端的Cookie或者URL中，那么Session真正的内容存储在哪里呢？ASP.NET 2.0对于Session内容的存储也提供了多种模式。

(1) InProc（默认）。Session存储在IIS进程中（Web服务器内存）。

(2) StateServer。Session存储在独立的Windows服务进程中（可以不是Web服务器）。

(3) SqlServer。Session存储在SqlServer数据库的表中（SqlServer服务器）。

虽然InProc模式的Session直接存储在Web服务器IIS进程中，速度比较快，但是每次重新启动IIS都会导致Session丢失。利用后两种模式，我们就完全可以把Session从 Web服务器中独立出来，从而减轻Web服务器的压力，同时减少Session丢失的概率。因此，SessionID存储在客户端（可以是Cookie或者URL），其他都存储在服务端（可以是IIS进程、独立的Windows服务进程或者SQL Server数据库中）。

3.3 服务端全局上下文Application

从Application这个单词上大致可以看出Application状态是整个应用程序全局的。在ASP时代我们通常会在Application中存储一些公共数据，而ASP.NET 中Application的基本意义没有变：在服务器内存中存储数量较少又独立于用户请求的数据。由于它的访问速度非常快而且只要应用程序不停止，数据一直存在，我们通常在Application_Start的时候去初始化一些数据，在以后的访问中可以迅速访问和检索。我们看到，Application的使用方法和Session差不多。唯一要注意的是，Application的作用范围是整个应用程序，可能有很多用户在同一个时间访问Application 造成并发混乱，因此在修改Application的时候需要先锁定Application，修改完成后再解锁。在ASP.NET 2.0中，Application已经变得不是非常重要了。因为Application的自我管理功能非常薄弱，它没有类似Session的超时机制。也就是说，Application中的数据只有通过手动删除或者修改才能释放内存，只要应用程序不停止，Application中的内容就不会消失。在下一节中，我们会看到，可以使用Cache实现类似Application的功能，同时Cache又有丰富而强大的自我管理机制。

3.4 可替代Application的上下文Cache

Cache 和Application一样是整个应用程序共用一份的，而且所有用户访问的都是相同的Cache。Cache从字面上说是缓存的意思，我们知道计算机系统本身就是一个多级缓存的结构。CPU的缓存中存放了部分内存中的数据，内存中又存放了部分硬盘中的数据。把最常用的数据放在读取最快速的硬件中存储能大大提高效率。对于Web系统来说也一样，从数据库（硬盘）中读取数据的速度肯定比从Cache（内存）中读取的效率低，基于这个特性，我们通常把改动不大而查询次数又比较多的数据放到Cache中。

既然缓存中的数据其实是来自数据库的，那么缓存中的数据如何和数据库进行同步呢？一般来说，缓存中应该存放改动不大或者对数据的实时性没有太多要求的数据。这样，我们只需要定期更新缓存就可以了。相反，如果缓存的更新频率过快的话，使用缓存的意义就不是很大了，因此更新缓存的时候需要一次性从数据库中读取大量的数据，过于频繁地更新缓存反而加重了数据库的负担。

3.5 混合式每用户上下文Profile

一个人性化的网站往往提供给用户很多个性化选择。比如让用户选择所喜欢的网站风格，让用户选择是否自动弹出消息提醒等。这些数据需要在用户把浏览器关闭后还能保存下来，因此只能选择数据库进行保存。对于登录过的用户比较好办，我们可以根据用户名和用户的选择存放在数据库中，对于非登录用户（匿名用户）怎么保存用户的选择呢？唯一的方法只能像Session那样分配给用户一个ID，把这个ID存放在Cookie中（当然也可以放在URL中），然后在数据库中保存这个ID相关的一些配置信息。

ASP.NET 2.0提供了Profile机制，能帮助我们完成类似的功能。Profile不仅仅支持登录用户还支持匿名用户，存储的数据也可以是任何可序列化类型。几乎无需写一行代码就能轻松实现用户个性化数据的保存。