最重要的 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� ......
package com.sj.main;
public class Snippet {
public static void main(String[] args){
//这个类主要是设置邮件
MailSenderInfo mailInfo = new MailSenderInfo();
String biaoti ="我是苏建，这是我的测试邮件";
String neirong = "我是苏建以下是我的测试邮件，欢迎大家� ......
3.1 跨平台三维图形开发工具包Java 3D
官方主页：https://java3d.dev.java.net/
Java 3D严格遵循“建模－绘制”泛型。场景图（scene graph）的 抽象模型被用来组织和维护虚拟场景中的可是对象及其行为。场景图包含了虚拟图形世界的全部信息，Java 3D绘 制引擎会对场景图进行自动绘制。
Java 3D is a scene g ......
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
/**
* 用于的使 Browser 不缓存页面的过滤器
*/
public class ForceNoCacheFilter
implements Filter
{
publi ......
