最重要的 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 中处理的。您必须对代码进行严格的检查和重构，以确�
相关文档：
package com.sj.main;
public class Snippet {
public static void main(String[] args){
//这个类主要是设置邮件
MailSenderInfo mailInfo = new MailSenderInfo();
String biaoti ="我是苏建，这是我的测试邮件";
String neirong = "我是苏建以下是我的测试邮件，欢迎大家� ......
今晚聊了一晚天，边看java 边聊天，没有集中精神去看。没搞懂java读取xml 的机制。看了一些书先把他记录一下。采用DOM文档对象模型，第一种方法来解析。听说这种解析会有一些缺点，不过总算调试通了，算是一种进步。
<?xml version="1.0" encoding="utf-8"?>
<item>
<node>aa</node&g ......
JAVA相关基础知识
1、面向对象的特征有哪些方面
1.抽象：
抽象就是忽略一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有关的方面。抽象并不打算了解全部问题，而只是选择其中的一部分，暂时不用部分细节。抽象包括两个方面，一是过程抽象，二是数据抽象。
2.继承：
继承是一种联结类的层次模型，并 ......
原文请看
http://www.ibm.com/developerworks/cn/websphere/techjournal/0701_botzum/0701_botzum.html
后续我会对下面提到的19点进行一些适当的批注,算是自己的读书笔记
引言
在过去的几乎整整十年中，人们编写了很多有关 Java™ Platform, Enterprise Edition (Java EE) 最佳实践的内容。现在有十多本书籍和数 ......
