学习JavaWeb的人没有不知道Servlet的吧，而要用Servlet就需要在web.xml中进行配置。相信有很多初学者跟我当初一样，对于一些配置参数不是很理解，今天就说说Servlet最基本的配置信息。
下面是一个最基本的Servlet配置：
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.Servlet.MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/Servlet</url-pattern>
</servlet-mapping>
Servlet的配置包括两部分：
1，<servlet>配置Servlet的名字和完整类路径：
servlet-name是自定义的，就是给Servlet取个名字。
servlet-class是Servlet完整的类，就是从一开始的包一直“.”到该Servlet。
2，<servlet-mapping>是用来截获请求的，包括servlet-name和url-pattern。
servlet-name跟<servlet>中的servlet-name是对应的，两个servlet-name一定要一致，否则会找不到对应的Servlet。
url-pattern是截获请求的规则，当表单提交的时候，会根据特定的规则调用相应的Servlet。下面会具体阐述。
url-pattern大致分为以下几种方式：
1，完全匹配
如：<url-pattern>/servlet/MyServlet.do</url-pattern>
2，目录匹配
如：<url-pattern>/servlet/*</url-pattern>
3，扩展名匹配
如：<url-pattern>*.do</url-pattern>
在web.xml文件中，以下语法用于定义映射：
l. 以”/’开头和以”/*”结尾的是用来做路径映射的。
2. 以前缀”*.”开头的是用来做扩展映射的。
3. “/” 是用来定义default servlet映射的。
4. 剩下的都是用来定义详细映射的。比如： /aa/bb/cc.action
容器查找规则：
1，容器会首先查找完全匹配，如果找不到，再查找目录匹配，如果也找不到，就查找扩展名匹配。
2，如果一个请求匹配多个“目录匹配”，容器会选择最长的匹配。
例如：servletA的url-pattern为/test/*，而servletB的url-pattern为/test/b/*，此 时访问http://localhost/test/b时，容器会选择路径最长的servlet来匹配，也就是这里的servletB。
注意：”/*.action”这样一个看起来很正常的匹配会错。因为这个匹配即属于路径映射，也属于扩展映射，会导致容器无法判断。
上面讲解的只是Servlet最基本的一个配置，还有很多其他的参数，有兴趣可自行研究，这里就不一一赘述了。欢迎交流探讨。
本文链接：http://www.cnblogs.com/liushuijinger/p/3256847.html，转载请注明。
继上一篇"订单系统开发(仿淘宝和美团网) 之 项目总结(一)"，这篇博客重点想说下订单系统开发的设计和有待优化改进的问题。
上图是订单系统数据库设计比较重要的一个——其决定了订单数据的横向切割，而不是将所有的订单数据都存放在一个表中。为什么要这样设计？这样做有什么好处？(看下文便可知晓) 回答上面的疑问，我感觉有必要引出另外一个问题:对于数据库设计，如何能降低并发量 或 提高数据的读写数度？我所知道和比较常见的做法如下：——
1.读写数据库分离，了解数据库的都知道：数据库的(读)共享锁S和(写)排它锁(X)是互斥、无法共存的，即当一个表的数据在被修改时，会阻止其它用户的读取。
2.数据库表的横向(行数据)和纵向(数据列)切割。
3.对于基本上不会用户查询的多个列，可以使用json或二进制等压缩序列化列字段存放数据，这样有点儿类似于Google的Big Table，有助于提高查询效率。
以上除了第一点在本次订单系统开发中都有使用，而且我相信你看完了上图，你应该会感觉到这样的数据切割：数据的存放(位置)比较清晰，比如：对于‘未付款’的订单数据，它一定是存放于Order_OrderInfo_Temp表中，这样：用户在搜索订单状态为“未付款”的订单时，可以很快方便的从此表中查询；或当用户在进行“取消交易”的操作时，基于上面第一点所提到的，它不会影响到处于'交易中'的订单用户的操作。
写到这儿，感觉有点儿戛然而止——不知道该写点儿啥了；回顾这个项目的开发历程，模糊→清晰→迷茫→纠结→释然，这就是我在项目的各个阶段的感受，用一句话来形容就是：由最开始的感觉高山仰止、举步维艰，到现在的“神马都是浮云”，困难都是暂时的，等你越过去(把它踩在脚下)，你也就感觉那算不上什么。
现在只想谈下，有待优化和比较棘手的地方——
1.目前的订单系统跟支付系统的相互依赖程度比较高，以至于订单的各个阶段的操作，如：付款，买家确认收货...，都需要调用支付系统的服务，以保证两边数据的同步。
2.由于支付系统是基于第三方支付平台相关服务方法的封装，即支付系统对“现金”进出操作只相当于是个通道，无法控制和保证每个操作的成功。
3.基于以上两点，订单系统与之交互的操作就比较被动，让人感觉很不舒服，增大了程序的复杂度。
4.订单和退款超时数据的处理，目前没有使用定时器或数据库job，暂时用几个触发点来代替，这样从服务到UI都增加了相应的代码处理。
怎样让订单系统和支付系统尽可能的'解耦'，这将是下一个版本需要重点解决的问题!
就写到这吧，希望有这方面经验的朋友，能提些建议。
本文链接：http://www.cnblogs.com/know/p/3256837.html，转载请注明。
没有评论:
发表评论