背景
失败是成功之母，前提是没有被遗忘的失败，本文记录这几天学习 Java，自己遇到的几个问题和解决方案，希望能达到强化记忆的作用。
开发环境是：Eclipse + Tomcat7.0。
第一个：依赖的第三方 jar 必须拷贝到 WEB-INF\lib 或 Tomcat 的 lib 目录
如果只是将第三方 jar 包添加到 build path 中只能保证编译通过，不能保证运行成功，关于如何配置运行期间类型的加载路径，我还没有查资料。
第二个：使用了 == 号
java 中不能重写运算符，对于 Class 和 Interface 来说，equals 的语义是值比较，== 的语义是引用比较。
第三个：在 Tomcat7.0 中使用了默认包
默认包中的类型在 JSP 中使用的时候，编译时没有问题，运行时就出错了。
第四个：在一个会话里测试 Page 指令的 isThreadSafe 配置
isThreadSafe 为 false 会导致所有请求串行化，为 true 会导致会话内的请求串行化。
如果你用同一个会话测试的话，true 和 false 的效果是一样的，使用两个浏览器可以到达期望的效果。
2 contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>
3 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
4 <html>
5 <head>
6 <meta http-equiv="Content-Type" content="text/html; utf-8">
7 <title>page 指令学习</title>
8 </head>
9 <body>
10 <p>isThreadSafe为false会导致所有请求串行化，为true会导致会话内的请求串行化。</p>
11 开始时间是：
12 <%
13 out.println(new java.util.Date());
14 %>
15 <br />
16 <%
17 Thread.sleep(5000);
18 %>
19 结束时间是：
20 <%
21 out.println(new java.util.Date());
22 %>
23 <br />
24 <%=Thread.currentThread().getId()%>
25 </body>
26 </html>
第五个：获取请求参数还要手工解码
不明白 Java 为啥不自动解码，是不是有地方可以配置？有知道的兄弟告诉我一下。
2 <%@ page language="java" contentType="text/html; charset=utf-8"
3 pageEncoding="utf-8"%>
4 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
5 <html>
6 <head>
7 <meta http-equiv="Content-Type" content="text/html; utf-8">
8 <title>request study</title>
9 </head>
10 <body>
11 <p>to get the parameter,you must set the character encoding first.</p>
12 <%
13 request.setCharacterEncoding("utf-8");
14 %>
15 <p>
16 get love:
17 <%
18 if (request.getParameter("love") != null) {
19 %>
20 <%=new String(request.getParameter("love").getBytes(
21 "iso-8859-1"), "utf-8")%>
22 <%
23 }
24 %>
25 </p>
26 <p>
27 post name:<%=request.getParameter("name")%></p>
28 <form method="get">
29 get form<input type="text" name="love" value="段光伟" /> <input
30 type="submit" />
31 </form>
32 <form method="post">
33 post form<input type="text" name="name" value="段光伟" /> <input
34 type="submit" />
35 </form>
36 </body>
37 </html>
备注
将自己的遇到的问题记录下来，即使是“白痴”级别的问题。
本文链接：http://www.cnblogs.com/happyframework/p/3349917.html，转载请注明。
上一篇文章写完，回复的人很多，有的说的很中肯，有的貌似只是看到文章的标题就进来写评论的！还有人问为什么我要屏蔽掉【反对】按钮，因为谁写文章都是为了分享，都在说出自己的心得体会。不过由于大家遇到的项目，做的东西，见过技术各有差异，很难让每个人都向一种意见靠拢。所以你可以不喜欢，但是请不要作恶！
评论中*深海， lindping说的是通用的ORM可以为通用产品带来部署的便利！dax.net，深蓝医生，路过秋天说的是ORM一个很关键的作用就是可以加快开发速度！还有些属于性能控，对SQL比较推崇。还有些没有明白表达的意图，语文是音乐老师教的！实在抱歉！
先说下部署这个问题，如果是做通用产品的话，考虑到各种数据库的兼容确实能带来很多好处。这一点我很认同，不过从业开始但现在，接触过的项目基本上都是属于定制类的，所以这一点没能感同身受。有过一次，不过不是换数据库这么简单，而是换整个部署方案，从WINDOW平台换到LINUX上，数据库从MSSQL换成ORACLE。没用ORM，用的SQLSHOP+存储过程的方式来做的系统，前后一个星期全部完工。因为SQLSHOP的SQL都是可以人工干涉的，存储过程这一类的调用也是放在SQLSHOP里面，所以我们基本上没有动一行代码，都是通过机器生产和人工的方式来修改存在XML里面的SQL，效果还可以。也是因为这次的经历，我才发现原来MSSQL和ORACLE其实差不了多少，存储过程，SQL函数，调用的语法，性能等等.Mono加JEXUS，有时比IIS还给力。
开发效率是评论中比较让我纠结的。因为我不是说我不用ORM，而是我觉得ORM设计的太复杂，没有什么太大的意义（原文第四句哈）！
主流的数据库，其增【INSERT INTO . (.,.)VALUES(.,.)】，删【DELETE FROM . WHERE ...】，改【UPDATE . SET .=. WHERE .=.】的语法都一样，这部分可以抽象，做出一个支持CUD（没有R）的系统。
但是查询就不是那么简单了，人们对数据的关注点不一样，所以需要的查询语句就不相同。不是所有主流数据库都有一个相同的查询系统，所以这一部分很难抽象。
所以没有一套ORM能很完美的处理了查询问题。
1.语法上，没法做到比SQL更简洁。
2.语义上，各库SQL方言的差异很大。你需要为每个主流数据库写一套不同的SQL方言系统，你需要了解各种库SQL的特点。
3.语用上，你需要动态生成符合当前情景的SQL。比如你做分页，每种库纯SQL的分页方言就有很多，每种分页在不同的分页情景下效率是不同的，最优的情况是你可以动态去判断情景。
上述三点，不说第三点。前两个弄得很好的ORM，开源的NHibernate没有做到，微软自己的EF没有做到，商用的LightSpeed也没有做到。目前的ORM都是在1和2上下功夫。3很难，而且对需求如此苛刻的也不会使用ORM了。所以，我倒是觉得与其活生生的坑在这三点上，倒不如从以下几个方面好好考虑一下，数据库支持，功能支持，语法支持，映射支持等。比如：
1.考虑下NOSQL吧，可以做完整单表映射或NOSQL数据的对象映射。
怎么支持RavenDB，STSdb，MongoDB，Cassandra等？
2.考虑下DDD吧。功能齐全的CUD系统，能否很好的支持CQRS中C？
怎样快速从数据库中映射出运行时对象？反射，EMIT，表达式？
怎么提高缓存的命中？支持Memcached，还是使用自己实现的？
3.考虑下支持OO原生特性，因为需要拿ORM来表达业务流程，是站在OO的角度考虑问题而不是数据库。那么你的ORM就需要考虑一些数据库问题了。
怎样为有继承关系的对象设计表？共享同一张表，还是分开，然后使用字段关联？
怎样选择更新时的充血或贫血？充血和贫血都有优缺点，怎样选择？
业务对象是可以用户实例化的还是只能由ORM实例化？用户实例化和ORM实例化各有各的好处，选择哪个?
可否为对象及对象的属性添加拦截？能够知道系统中最热对象是哪个，最热属性是哪个，由此可以得出一些很有意思的信息在，怎么设计？
......
这实在是太多了，不管是细节还是宏观上，都太多了。
4.考虑下支持从数据库直接映射成XML或JSON吧，或把XML或JSON直接转换为SQL吧，虽然XML和JSON不是对象，但是越来越多的地方使用XML或JSON来做对象容器。
说完查询SQL生成的复杂，再说业务逻辑的问题。把复杂逻辑放在代码，还是放在数据库里面。其实这个也很让人纠结。站在数据库的角度想，在离数据越近的地方处理数据越快，所以放在数据库里面吧。但是站在代码的角度考虑，各种对象组合在一个表达了一套完整的业务流程，用OO的方式去考虑这个流程远比使用数据库表结构去表达要好很多，所以放在代码里面吧！......评论中地狱门神的评论很直接，我也很想这么做。但是有时候，完全使用代码去完成一套业务流程是不靠谱的。使用存储过程的时候，一切都是在数据库中，少了从数据库表到运行时对象的转换，肯定会快很多。而且业务流程越复杂，这一点体现的越明显。如果你的系统中有个部分是和很多表关联的，比如权限模块，你用ADO.NET到OBJECT，再处理OBJECT，再使用OBJECT和ADO.NET获取新的OBJECT的这种串行化的方式处理业务流程，当表的关联到达一定程度的时候，那个速度是完完全全不能忍受的。这个时候就需要使用存储过程了。
所以根据以往的经验，使用存储过程的地方主要是两点。
1.如果有部分的业务变化比较频繁并且有一些性能要求，使用存储过程吧，这样在系统运行时就能轻松的修复一些问题。
2.如果一个流程关联的表比较多（多于3张以上的表），而且每个表的数据都超过1W，那么也用存储过程吧。
如果对性能要求不高，表关联也不多，业务流程很简单，那就可以使用代码的方式来表达业务流程了。
所以，想想吧！
复杂查询SQL，就算是再复杂的ORM也玩不来的，与其如此，倒不如设计的简单易用些。
不要再为ORM考虑怎么全部的CURD都是对象操作，怎么全部的查询SQL都是自动生成，怎么设计支持多表关联了。
作为程序员，何必活的那么复杂，大道至简！
本文链接：http://www.cnblogs.com/wushilonng/p/3349512.html，转载请注明。
没有评论:
发表评论