最重要的 Java EE 最佳实践 1. 始终使用 MVC 框架
1. 始终使用 MVC 框架。
将业务逻辑（Java Bean 和 EJB 组件）从控制器逻辑（Servlet/Struts 操作）和表示逻辑（JSP、XML/XSLT）中清晰地分离出来。良好的分层可以带来许多好处。
注:对于一些小型的或者业务相对简单的系统而言,用框架开发并不能带来任何效益,并且我深信在一些项目开发中,特别是仅仅由某个人独立开发的, 那么往往是无法体会到MVC的好处的,也不会怎么去参考这样的一些建议,但是提前的参考这些建议或者规范,对我们以后的成长是应该很有好处的.
这项实践非常重要，以致没有其他最佳实践可以与其相提并论。对于良好的 Java EE 应用程序设计而言，模型-视图-控制器 (MVC) 是至关重要的。它将程序的任务简单地分为下面几个部分：
负责业务逻辑的部分（模型，通常使用 Enterprise JavaBeans™ 或传统 Java 对象来实现）。(注:这部分在业务没有变更的时候是不需要修改的)
负责用户接口表示的部分（视图）。(注:这部分是在界面改版或者调优的时候需要修改的)
负责应用程序导航的部分（控制器，通常使用 Java Servlet 或类 Struts 控制器这样相关的类来实现）。(注:这部分是前两个部分的中间接口部分,相对修改的频率会高点)
注:这里的层次在分析的时候或者后期维护的时候,是有很多好处的,最直接的,就是能很容易的找到问题点.而不需要牵扯到太多的面
如果不遵循基本的 MVC 体系结构，在开发过程中就会出现许多的问题。最常见的问题是，将过多的任务放到该体系结构的视图部分中。可能存在使用 JSP 标记来执行数据库访问，或者在 JSP 中进行应用程序的流程控制，这在小规模的应用程序中是比较常见的，但是，随着后期的开发，这样做将会带来问题，因为 JSP 逐步变得越来越难以维护和调试。
注:没有做过大系统的人,或许不是很容易体会到这一点,不过我对这一点是深信不疑的.我曾经做过一个mrp的改版,的确是很头痛的事情.
类似地，我们也经常看到将视图层构建到业务逻辑的情况。例如，一个常见的问题就是将在构建视图时使用的 XML 解析技术直接应用到业务层。业务层应该对业务对象进行操作，而不是对与视图相关的特定数据表示进行操作。
然而，仅仅使用适当的组件无法实现应用程序的正确分层。我们常常见到一些应用程序包含 Servlet、JSP 和 EJB 组件所有这三项，然而，其主要的业务逻辑却是在 Servlet 层实现的，或者应用程序导航是在 JSP 中处理的。您必须对代码进行严格的检查和重构，以确�
相关文档：
post和get的区别：
get是通过URL向服务器递交数据，即提交的相关信息包含在地址栏的URL中
post提交后地址栏不变
可以通过Java.net.URLEncoder将中文字符变为可以加在URL中用于查询的编码，相应的，Java.net.URLDecoder用于相关的解码
Apache开源组织中的httpclient，它隶属于Jakarta的commons项目，专门设计来简化HTTP� ......
=====suppose such a method:
public static void openFile(String fileName, PrintWriter stream) throws FileNotFoundException
{
stream = new PrintWriter(fileName);
}
=====then we want to use it this way:
PrintWriter toFile = null;
try
{
openFile("data.txt", t ......
简而言之，这两个类是用来利用正则表达式验证字符串有效性的。
Pattern类用来定义正则表达式规则，Matcher类用来定义要验证的字符串。
用法：
Pattern p = Pattern.compile("a*b");
Matcher m = p.matcher("aaaaab");
boolean b = m.matches();
当然，也可以直接用Pattern类直接验证，用法：
boolean ......
1、语法：必须比较熟悉，在写代码的时候IDE的编辑器对某一行报错应该能够根据报错信息知道是什么样的语法错误并且知道任何修正。
2、命令：必须熟悉JDK带的一些常用命令及其常用选项，命令至少需要熟悉：appletviewer、 HtmlConverter、jar、 java、javac、javadoc、javap、javaw、native2ascii、serialver，如果这些命� ......
