最重要的 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 中处理的。您必须对代码进行严格的检查和重构，以确�
相关文档：
Date ---->String
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
String date = sdf.fomat(new Date());
String ---->Date
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
Date date = sdf.parse("2010-03-16");
日期比较大小，这就用到了Date类中的before()和after()方� ......
PO VO BO DTO POJO DAO们的概念
J2EE开发中大量的专业缩略语很是让人迷惑，尤其是跟一些高手讨论问题的时候，三分钟就被人家满口的专业术语喷晕了，PO VO BO DTO POJO DAO，一大堆的就来了（听过老罗对这种现象的批判的朋友会会心一笑）。
首先声明偶也不是什么高手，以下总结都是自己的体会。不对之� ......
记得在csdn的某个帖子中提到计算阶乘的讨论，当时有很多人都提出了自己的算法，每个人都想的很周全。
这两天正好自己看到了相关的文章，那么总结整理一下，以供大家参考，也为了自己的知识总结。
在数学中，只有非负整数才有阶乘运算，意思就是说浮点数、负整数都不能进行计算，那么我们在考虑计算时，小于0的数字我们是� ......
首先，建3个接口
FTPOperate.java:
public interface FTPOperate
{
public void execute(FTPBean entity);
}
FTPProxy.java:
public interface FTPProxy
{
public void connection();
public abstract void upload();
public abstract void download();
public void setEntity(FTPBe ......
