初识Java内部类
    提起Java内部类(Inner Class)可能很多人不太熟悉,实际上类似的概念在C++里也有,那就是嵌套类(Nested Class),关于这两者的区别与联系,在下文中会有对比。内部类从表面上看,就是在类中又定义了一个类(下文会看到,内部类可以在很多地方定义),而实际上并没有那么简单,乍看上去内部类似乎有些多余,它的用处对于初学者来说可能并不是那么显著,但是随着对它的深入了解,你会发现Java的设计者在内部类身上的确是用心良苦。学会使用内部类,是掌握Java高级编程的一部分,它可以让你更优雅地设计你的程序结构。下面从以下几个方面来介绍:
    ·第一次见面
public interface Contents {
    int value();
}
public interface Destination {
    String readLabel();
}
public class Goods {
    private class Content implements Contents {
        private int i = 11;
        public int value() {
            return i;
        }
    }
    protected class GDestination implements Destination {
        private String label;
        private GDestination(String whereTo) {
            label = whereTo;
        }
        public String readLabel() {
            return label;
        }
    }
    public Destination dest(String s) {
        return new GDestination(s);
    }
    public Contents cont() {
        return new Content();
    }
}
class TestGoods {
    public static void main(String[] args) {
        Goods p = new Goods();
        Contents c = p.cont();
        Destination d = p.dest("Beijing");
    }
}
    在这个例子里类Content和GDestination被定义在了类Goods内部,并且分别有着protected和private修饰符来控制访问级别。Content代表着Goods的内容,而GDestination代表着Goods的目的地。它们分别实现了两个接口Content和Destination。在后面的main方法里,直接用 Contents c和Destination d进行操作,你甚至连这两个内部类的名字都没有看见!这样,内部类的第一个好处就体现出来了——隐藏你不想让别人知道的操作,也即封装性。
    同时,我们也发现了在外部类作用范围之外得到内部类对象的第一个方法,那就是利用其外部类的方法创建并返回。上例中的cont()和dest()方法就是这么做的。那么还有没有别的方法呢?当然有,其语法格式如下:
    outerObject=new outerClass(Constructor Parameters);
    outerClass.innerClass innerObject=outerObject.new InnerClass(Constructor Parameters);
    注意在创建非静态内部类对象时,一定要先创建起相应的外部类对象。至于原因,也就引出了我们下一个话题——
    ·非静态内部类对象有着指向其外部类对象的引用
    对刚才的例子稍作修改:
public class Goods {
    private valueRate=2;
    private class Content implements Contents {
        private int i = 11*valueRate;
        public int value() {
            return i;
        }
    }
    protected class GDestination implements Destination {
        private String label;
        private GDestination(String whereTo) {
            label = whereTo;
        }
        public String readLabel() {
            return label;
        }
    }
    public Destination dest(String s) {
        return new GDestination(s);
    }
    public Contents cont() {
        return new Content();
    }
}
    修改的部分用蓝色显示了。在这里我们给Goods类增加了一个private成员变量valueRate,意义是货物的价值系数,在内部类Content的方法value()计算价值时把它乘上。我们发现,value()可以访问valueRate,这也是内部类的第二个好处——一个内部类对象可以访问创建它的外部类对象的内容,甚至包括私有变量!这是一个非常有用的特性,为我们在设计时提供了更多的思路和捷径。要想实现这个功能,内部类对象就必须有指向外部类对象的引用。Java编译器在创建内部类对象时,隐式的把其外部类对象的引用也传了进去并一直保存着。这样就使得内部类对象始终可以访问其外部类对象,同时这也是为什么在外部类作用范围之外向要创建内部类对象必须先创建其外部类对象的原因。
    有人会问,如果内部类里的一个成员变量与外部类的一个成员变量同名,也即外部类的同名成员变量被屏蔽了,怎么办?没事,Java里用如下格式表达外部类的引用:
outerClass.this
    有了它,我们就不怕这种屏蔽的情况了。
    ·静态内部类
    和普通的类一样,内部类也可以有静态的。不过和非静态内部类相比,区别就在于静态内部类没有了指向外部的引用。这实际上和C++中的嵌套类很相像了,Java内部类与C++嵌套类最大的不同就在于是否有指向外部的引用这一点上,当然从设计的角度以及以它一些细节来讲还有区别。
    除此之外,在任何非静态内部类中,都不能有静态数据,静态方法或者又一个静态内部类(内部类的嵌套可以不止一层)。不过静态内部类中却可以拥有这一切。这也算是两者的第二个区别吧。
    ·局部内部类
    是的,Java内部类也可以是局部的,它可以定义在一个方法甚至一个代码块之内。
public class Goods1 {
     public Destination dest(String s) {
          class GDestination implements Destination {
               private String label;
               private GDestination(String whereTo) {
                    label = whereTo;
               }
               public String readLabel() { return label; }
          }
          return new GDestination(s);
     }
     public static void main(String[] args) {
          Goods1 g= new Goods1();
          Destination d = g.dest("Beijing");
     }
}
    上面就是这样一个例子。在方法dest中我们定义了一个内部类,最后由这个方法返回这个内部类的对象。如果我们在用一个内部类的时候仅需要创建它的一个对象并创给外部,就可以这样做。当然,定义在方法中的内部类可以使设计多样化,用途绝不仅仅在这一点。
    下面有一个更怪的例子:
public class Goods2{
     private void internalTracking(boolean b) {
          if(b) {
               class TrackingSlip {
                    private String id;
                    TrackingSlip(String s) {
                         id = s;
                    }
                    String getSlip() { return id; }
               }
               TrackingSlip ts = new TrackingSlip("slip");
               String s = ts.getSlip();
          }
     }
     public void track() { internalTracking(true); }
     public static void main(String[] args) {
          Goods2 g= new Goods2();
          g.track();
     }
}
    你不能在if之外创建这个内部类的对象,因为这已经超出了它的作用域。不过在编译的时候,内部类TrackingSlip和其他类一样同时被编译,只不过它由它自己的作用域,超出了这个范围就无效,除此之外它和其他内部类并没有区别。
    ·匿名内部类
    java的匿名内部类的语法规则看上去有些古怪,不过如同匿名数组一样,当你只需要创建一个类的对象而且用不上它的名字时,使用内部类可以使代码看上去简洁清楚。它的语法规则是这样的:
    new interfacename(){......}; 或 new superclassname(){......};
    下面接着前面继续举例子:
public class Goods3 {
     public Contents cont(){
          return new Contents(){
               private int i = 11;
               public int value() {
                    return i;
               }
          };
     }
}
    这里方法cont()使用匿名内部类直接返回了一个实现了接口Contents的类的对象,看上去的确十分简洁。
    在java的事件处理的匿名适配器中,匿名内部类被大量的使用。例如在想关闭窗口时加上这样一句代码:
frame.addWindowListener(new WindowAdapter(){
     public void windowClosing(WindowEvent e){
          System.exit(0);
     }
});
    有一点需要注意的是,匿名内部类由于没有名字,所以它没有构造函数(但是如果这个匿名内部类继承了一个只含有带参数构造函数的父类,创建它的时候必须带上这些参数,并在实现的过程中使用super关键字调用相应的内容)。如果你想要初始化它的成员变量,有下面几种方法:
    1.如果是在一个方法的匿名内部类,可以利用这个方法传进你想要的参数,不过记住,这些参数必须被声明为final。
    2.将匿名内部类改造成有名字的局部内部类,这样它就可以拥有构造函数了。
    3.在这个匿名内部类中使用初始化代码块。
    ·为什么需要内部类?
    java内部类有什么好处?为什么需要内部类?
    首先举一个简单的例子,如果你想实现一个接口,但是这个接口中的一个方法和你构想的这个类中的一个方法的名称,参数相同,你应该怎么办?这时候,你可以建一个内部类实现这个接口。由于内部类对外部类的所有内容都是可访问的,所以这样做可以完成所有你直接实现这个接口的功能。
    不过你可能要质疑,更改一下方法的不就行了吗?
    的确,以此作为设计内部类的理由,实在没有说服力。
    真正的原因是这样的,java中的内部类和接口加在一起,可以的解决常被C++程序员抱怨java中存在的一个问题——没有多继承。实际上,C++的多继承设计起来很复杂,而java通过内部类加上接口,可以很好的实现多继承的效果。

posted @ 2006-03-02 20:54 killvin| 编辑 收藏

引言
在使用response的过程中经常会遇到跳转页面的事情,这个时候有两种情况供你选择
1。就是调用
ServletContext.getRequestDispatcher(java.lang.String).forward(request ,
response) ;
2。就是调用response.setRedirect(),可是这两个方法有什么不同呢?


看看TSS上关于这个问题的解释:
Difference request.forward() and response.sendRedirect .
Posted by: Kapil Israni on August 24, 2000 in response to Message #2253 1
replies in this thread
i suppose u r talking bout requestDispatcher.forward() here.

well basically both method calls redirect u to new resource/page/servlet.

the difference between the two is that sendRedirect always sends a header
back to the client/browser. this header then contains the
resource(page/servlet) which u wanted to be redirected. the browser uses
this header to make another fresh request. thus sendRedirect has a overhead
as to the extra remort trip being incurred. its like any other Http request
being generated by ur browser. the advantage is that u can point to any
resource(whether on the same domain or some other domain). for eg if
sendRedirect was called at www.mydomain.com then it can also be used to
redirect a call to a resource on www.theserverside.com.

where as in case of forward() call, the above is not true. resources from
the server, where the fwd. call was made, can only be requested for. but
the major diff between the two is that forward just routes the request to
the new resources which u specify in ur forward call. that means this route
is made by the servlet engine at the server level only. no headers r sent
to the browser which makes this very eficient. also the request and
response objects remain the same both from where the forward call was made
and the resource which was called.

i hope i have hit ur question right.

posted @ 2006-03-02 20:54 killvin| 编辑 收藏

Java Language Keywords

Here's a list of keywords in the Java language. These words are reserved — you cannot use any of these words as names in your programs. true, false, and null are not keywords but they are reserved words, so you cannot use them as names in your programs either.

abstract    |   continue    |   for    |    new     |   switch
assert***  |   default     |   goto*     |   package     |   synchronized
boolean    |   do     |   if     |   private     |   this
break         |   double     |   implements    |   protected    |   throw
byte            |   else     |   import     |   public  throws
case          |   enum****    |   instanceof    |   return     |   transient 
catch         |   extends     |   int     |   short     |   try
char           |   final     |   interface    |   static     |   void
class         |   finally     |   long     |   strictfp**    |   volatile
const*       |   float     |   native     |   super     |   while


*   not used
**   added in 1.2
***   added in 1.4 
****   added in 5.0                                    

 

Key: strictfp**

使用对象:类、方法

自Java2以来,Java语言增加了一个关键字strictfp,虽然这个关键字在大多数场合比较少用,但是还是有必要了解一下。

strictfp的意思是FP-strict,也就是说精确浮点的意思。在Java虚拟机进行浮点运算时,如果没有指定strictfp关键字时,Java的编译器以及运行环境在对浮点运算的表达式是采取一种近似于我行我素的行为来完成这些操作,以致于得到的结果往往无法令你满意。而一旦使用了strictfp来声明一个类、接口或者方法时,那么所声明的范围内Java的编译器以及运行环境会完全依照浮点规范IEEE-754来执行。因此如果你想让你的浮点运算更加精确,而且不会因为不同的硬件平台所执行的结果不一致的话,那就请用关键字strictfp。

你可以将一个类、接口以及方法声明为strictfp,但是不允许对接口中的方法以及构造函数声明strictfp关键字,例如下面的代码:

1. 合法的使用关键字strictfp

strictfp interface A {}

public strictfp class FpDemo1 {
    strictfp void f() {}
}

2. 错误的使用方法

interface A {
    strictfp void f();
}

public class FpDemo2 {
    strictfp FpDemo2() {}
}

一旦使用了关键字strictfp来声明某个类、接口或者方法时,那么在这个关键字所声明的范围内所有浮点运算都是精确的,符合IEEE-754规范的。例如一个类被声明为strictfp,那么该类中所有的方法都是strictfp的。

 

Keys: volatile

使用对象:字段

介绍:因为异步线程可以访问字段,所以有些优化操作是一定不能作用在字段上的。volatile有时

可以代替synchronized。

 

Keys:transient

  使用对象:字段

  介绍:字段不是对象持久状态的一部分,不应该把字段和对象一起串起。

posted @ 2006-03-02 20:53 killvin| 编辑 收藏

引言

 记得当初参与某公司的ERP项目中,接触过异常框架这个概念,可是似乎并没有感觉到当时技术经理提出这个概念的意义,而且他也对这个概念似乎很"保守",虽然按照他的思路去执行,但没有理解的概念再实施起来的时候总是觉得很"别扭",而如今面对自己要设计咚咚了,不得不重新审视异常这个概念,JAVA异常的介绍文章在网络上非常的少,而对于如何构件J2EE的异常处理框架更显的稀少,于是就促使自己写下了这样的文章。

 本文只是自己的一些愚见,希望和大家相互学习。Email:Killvin@hotmail.com

概念

什么是异常?

异常(exception)应该是异常事件(exceptional event)的缩写。
异常定义:异常是一个在程序执行期间发生的事件,它中断正在执行的程序的正常的指令流。
当在一个方法中发生错误的时候,这个方法创建一个对象,并且把它传递给运行时系统。这个对象被叫做异常对象,它包含了有关错误的信息,这些信息包括错误的类型和在程序发生错误时的状态。创建一个错误对象并把它传递给运行时系统被叫做抛出异常。
一个方法抛出异常后,运行时系统就会试着查找一些方法来处理它。这些处理异常的可能的方法的集合是被整理在一起的方法列表,这些方法能够被发生错误的方法调用。这个方法列表被叫做堆栈调用(call stack)

运行时系统搜寻包含能够处理异常的代码块的方法所请求的堆栈。这个代码块叫做异常处理器,搜寻首先从发生的方法开始,然后依次按着调用方法的倒序检索调用堆栈。当找到一个相应的处理器时,运行时系统就把异常传递给这个处理器。一个异常处理器要适当地考滤抛出的异常对象的类型和异常处理器所处理的异常的类型是否匹配。异常被捕获以后,异常处理器关闭。如果运行时系统搜寻了这个方法的所有的调用堆栈,而没有找到相应的异常处理器。

 

怎么设计异常框架

任何的异常都是Throwable类(为何不是接口??),并且在它之下包含两个字类Error / Exception,而Error仅在当在Java虚拟机中发生动态连接失败或其它的定位失败的时候,Java虚拟机抛出一个Error对象。典型的简易程序不捕获或抛出Errors对象,你可能永远不会遇到需要实例化Error的应用,那就让我们关心一下Exception

Exception中比较重要的就是RuntimeException-运行时异常(当然这个名字是存在争议的,因为任何的异常都只会发生在运行时),为什么说这个类时很重要的呢?因为它直接关系到你的异常框架的设计,仔细看RuntimeException

A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

-可能在执行方法期间抛出但未被捕获的 RuntimeException 的任何子类都无需在 throws 子句中进行声明。

也就是说你的应用应该不去“关心”(说不关心是不服责任的,但只是你不应该试图实例化它的字类)RuntimeException,就如同你不应该关心Error的产生与处理一样!RuntimeException描述的是程序的错误引起来的,因该由程序负担这个责任!(<B>从责任这个角度看Error属于JVM需要负担的责任;RuntimeException是程序应该负担的责任;checked exception 是具体应用负担的责任</B>)

那就有人会问,那我该关心什么!答案就是除了Error与RuntimeException,其他剩下的异常都是你需要关心的,而这些异常类统称为Checked Exception,至于Error与RuntimeException则被统称为Unchecked Exception.


异常的概念就这些了,即使你在网络上搜索也就不过如此,是不是感觉到有点清晰又有点模糊?那么怎么该如何在这样单薄而模糊的概念下设计J2EE的异常框架呢?


解决方案:J2EE异常框架

我们拿一个模拟的例子来说明异常框架的设计过程,比如我们要对外提供doBusiness()这个业务方法

public void doBusiness() throws xxxBusinessException

当客户端调用这样的方法的时候应该这样处理异常(包括处理RuntimeException , checked exception)
<B>记住,无论如何我们都不希望或者确切的说是不应该将RuntimeException这样的异常暴露给客户的,因为他们没有解决这个问题的责任!</B>
我们暂时将Struts中的某个Action看作时客户端,其中doExecute(....)要调用doBusiness()这个方法

public void doAction(......)
{
 try
 {

  xxx.doBusiness();
 }
 catch(Exception e)
 {
   if(e instanceof RuntimeException) 
   {
    // catch runtime exception
    // 你可以在这里将捕获到的RuntimeException
    // 将异常通知给某个负责此程序的程序员,让他知道他
    // 自己犯了多么低级的错误!


   }else
   {
    //checked exception such as xxxBusinessException
    //将这样的异常暴露给客户显示    

   }

 }
}

我们可以这样设计xxxBusinessException

public class xxxBusinessException extends ApplicationException
{
    public xxxBusinessException(String s){
        super(s);

};

import java.io.PrintStream;
import java.io.PrintWriter;
public class ApplicationException extends Exception {
       /** A wrapped Throwable */
       protected Throwable cause;
       public ApplicationException() {
           super("Error occurred in application.");
       }
       public ApplicationException(String message)  {
           super(message);
       }
       public ApplicationException(String message, Throwable cause)  {
           super(message);
           this.cause = cause;
       }
       // Created to match the JDK 1.4 Throwable method.
       public Throwable initCause(Throwable cause)  {
           this.cause = cause;
           return cause;
       }
       public String getMessage() {
           // Get this exception's message.
           String msg = super.getMessage();
           Throwable parent = this;
           Throwable child;
           // Look for nested exceptions.
           while((child = getNestedException(parent)) != null) {
               // Get the child's message.
               String msg2 = child.getMessage();
               // If we found a message for the child exception,
               // we append it.
               if (msg2 != null) {
                   if (msg != null) {
                       msg += ": " + msg2;
                   } else {
                       msg = msg2;
                   }
               }
               // Any nested ApplicationException will append its own
               // children, so we need to break out of here.
               if (child instanceof ApplicationException) {
                   break;
               }
               parent = child;
           }
           // Return the completed message.
           return msg;
       }
       public void printStackTrace() {
           // Print the stack trace for this exception.
           super.printStackTrace();
           Throwable parent = this;
           Throwable child;
           // Print the stack trace for each nested exception.
           while((child = getNestedException(parent)) != null) {
               if (child != null) {
                   System.err.print("Caused by: ");
                   child.printStackTrace();
                   if (child instanceof ApplicationException) {
                       break;
                   }
                   parent = child;
               }
           }
       }
       public void printStackTrace(PrintStream s) {
           // Print the stack trace for this exception.
           super.printStackTrace(s);
           Throwable parent = this;
           Throwable child;
           // Print the stack trace for each nested exception.
           while((child = getNestedException(parent)) != null) {
               if (child != null) {
                   s.print("Caused by: ");
                   child.printStackTrace(s);
                   if (child instanceof ApplicationException) {
                       break;
                   }
                   parent = child;
               }
           }
       }
       public void printStackTrace(PrintWriter w) {
           // Print the stack trace for this exception.
           super.printStackTrace(w);
           Throwable parent = this;
           Throwable child;
           // Print the stack trace for each nested exception.
           while((child = getNestedException(parent)) != null) {
               if (child != null) {
                   w.print("Caused by: ");
                   child.printStackTrace(w);
                   if (child instanceof ApplicationException) {
                       break;
                   }
                   parent = child;
               }
           }
       }
       public Throwable getCause()  {
           return cause;
       }
}

而"聪明"的读者肯定要问我那doBusiness()这个业务方法该如何包装异常呢?

 public void doBusiness() throw xxxBusinessException
 {
   try
   {
     execute1(); // if it throw exception1

     exexute2(); // if it throw exception 2

     .... .....

   }
   catch (exception1 e1)
   {
    throw new xxxBusinessException(e1);
   }
   catch(exception2 e2)
   {
    throw new xxxBusinessException(e2);
   }
   ........
 }

 也可以这样

 public void doBusiness() throw xxxBusinessException
 {
   try
   {
     execute1(); // if it throw exception1

     exexute2(); // if it throw exception 2

     .... .....

   }
   catch (Exception e)
   {
    // 注意很多应用在这里根本不判断异常的类型而一股脑的采用
    // throw new xxxBusinessException(e);
    // 而这样带来的问题就是xxxBusinessException"吞掉了"RuntimeException
    // 从而将checked excption 与unchecked exception混在了一起!

    // 其实xxxBusinessException属于checked excpetion ,它根本不应该也不能够理睬RuntimeException
    if(! e instanceof RuntimeException) throw new xxxBusinessException(e);
   }
 }


总结
 1。JAVA的异常分为两类: checked exception & unchecked excpetion
 2。应用开发中产生的异常都应该集成自Exception 但都属于checked excpetion类型
 3。应用中的每一层在包装并传递异常的时候要过滤掉RuntimeException!
 4。从责任这个角度看Error属于JVM需要负担的责任;RuntimeException是程序应该负担的责任;checked exception 是具体应用负担的责任
 5。无论如何我们都不希望或者确切的说是不应该将RuntimeException这样的异常暴露给客户的,因为他们没有解决这个问题的责任!

posted @ 2006-03-02 20:50 killvin| 编辑 收藏

Nasted Class 的介绍,请详见参考

今天讨论的不是不是内部类的概念,而是具体使用的一个场景-如何在内部类中返回外部对象

看一段代码

import java.util.LinkedList;
import java.util.List;


public class OuterClass
{

 private List listeners = new LinkedList();

 public void addListeners(IListener listener)
 {
  this.listeners.add(listener);
 }


 private OuterClass outer = this;  (1)
 private class InnterClass
 {
  public void publish()
  {
   //将事件发布出去 (2)
   for(int i=0;i < listeners.size();i++)
   {
    IListener listener = (IListener) listeners.get(i);
    listener.receiveEvent(outer);
   }

  }
 }


 public void execute()
 {
  InnterClass in = new InnterClass(); (3)
  in.publish();

 }
}

public interface IListener
{

public void receiveEvent(OuterClass obj);
}

你可能觉得这个例子很别扭,在哪里让你觉得难受呢?其实问题的关键就在于接口IListener的定义,这里需要给receiveEvent方法传递的参数是外部对象!(别激动,下面我会说明需要传递的一个场景)

场景

在一个GUI系统中,我们要在画板WorkSpace(WorkSpace实现了IListener接口)上产生一颗树,但树中的每个节点的产生(绘图)是我们不知道的算法,系统只为我们提供了一些绘图的接口,并返回元素的句柄!看来我们需要"包装"一下这个绘图的句柄Brush(其实我把它叫做笔刷,因为它只知道如何"刷"出图像来,就这点本事!)并对外提供节点Node这样一个通用的类。

此时Node与Brush的关系就很微妙了,不过我们可以抛开这些外表,看到Node与Brush其实就是外部类与内部类的关系!-第一步完成了:确定了两者的关系

然而,事情没有这么简单,Node类必须处理一些事件,而这些事件理所当然只有Brush能够看懂,而Node根本不知道这样的事件处理过程,现在有两个办法:办法一,让Node实现Brush所有的事件;办法二,把Brush返回回去,让它来处理自己的事件,看来办法二是个好主意,因为我可以不关心事件的种类!-第二步完成了:确定了事件处理的责任

还没完呢,你肯定不希望画板WorkSpace面对的是绘图的句柄Brush这样的对象,相反你只希望WokSpace只知道Node的存在!IListener接口中receiveEvent方法的参数定义为OuterClass 就由此而来!-第三步完成:接口的定义

public interface IListener
{

public void receiveEvent(OuterClass obj);
}

 既然说清楚了这个问题(应该比较清楚了吧?)那改如何实现这样一个蹩脚而有无可奈何的设计呢?让我们回忆一下内部类,内部类拥有访问外部类的方法与属性的权限

 private OuterClass outer = this;  - 这个对外部类的引用就是为内部类的访问准备的

 private class InnterClass
 {
  public void publish()
  {
   //将事件发布出去 

   for(int i=0;i < listeners.size();i++)
   {
    IListener listener = (IListener) listeners.get(i);
    listener.receiveEvent(outer);  - 这里不可以返回this,因为this代表的是内部类自己
   }
  }

 

 

参考

Java Nested class   http://blog.csdn.net/Killvin/archive/2006/01/10/574983.aspx

初识Java内部类    http://blog.csdn.net/killvin/archive/2006/01/10/574991.aspx

posted @ 2006-03-02 20:49 killvin| 编辑 收藏

当你显式的使用session.save()或者session.update()操作一个对象的时候,实际上是用不到unsaved-value的。某些情况下(父子表关联保存),当你在程序中并没有显式的使用save或者update一个持久对象,那么Hibernate需要判断被操作的对象究竟是一个已经持久化过的持久对象,是一个尚未被持久化过的内存临时对象。例如:

java代码: 

  Session session = ...;
  Transaction tx = ...;
  
  Parent parent = (Parent) session.load(Parent.class, id);
  
  Child child = new Child();
  child.setParent(parent);
  child.setName("sun");
  
 10 parent.addChild(child);
 11 s.update(parent);
 12 
 13 s.flush();
 14 tx.commit();
 15 s.close();



在上例中,程序并没有显式的session.save(child); 那么Hibernate需要知道child究竟是一个临时对象,还是已经在数据库中有的持久对象。如果child是一个新创建的临时对象(本例中就是这种情况),那么Hibernate应该自动产生session.save(child)这样的操作,如果child是已经在数据库中有的持久对象,那么Hibernate应该自动产生session.update(child)这样的操作。

因此我们需要暗示一下Hibernate,究竟child对象应该对它自动save还是update。在上例中,显然我们应该暗示Hibernate对child自动save,而不是自动update。那么Hibernate如何判断究竟对child是save还是update呢?它会取一下child的主键属性 child.getId() ,这里假设id是 java.lang.Integer类型的。如果取到的Id值和hbm映射文件中指定的unsave-value相等,那么Hibernate认为child是新的内存临时对象,发送save,如果不相等,那么Hibernate认为child是已经持久过的对象,发送update。

unsaved-value="null" (默认情况,适用于大多数对象类型主键 Integer/Long/String/...)

当Hibernate取一下child的Id,取出来的是null(在上例中肯定取出来的是null),和unsaved-value设定值相等,发送save(child)

当Hibernate取一下child的id,取出来的不是null,那么和unsaved-value设定值不相等,发送update(child)

例如下面的情况:

java代码: 

  Session session = ...;
  Transaction tx = ...;
  
  Parent parent = (Parent) session.load(Parent.class, id);
  Child child = (Child) session.load(Child.class, childId);
  
  child.setParent(parent);
  child.setName("sun");
  
 10 parent.addChild(child);
 11 s.update(parent);
 12 
 13 s.flush();
 14 tx.commit();
 15 s.close();



child已经在数据库中有了,是一个持久化的对象,不是新创建的,因此我们希望Hibernate发送update(child),在该例中,Hibernate取一下child.getId(),和unsave-value指定的null比对一下,发现不相等,那么发送update(child)。

BTW: parent对象不需要操心,因为程序显式的对parent有load操作和update的操作,不需要Hibernate自己来判断究竟是save还是update了。我们要注意的只是child对象的操作。另外unsaved-value是定义在Child类的主键属性中的。

java代码: 

 1 <class name="Child" table="child">
 2 <id column="id" name="id" type="integer" unsaved-value="null">
 3   <generator class="identity"/>
 4 </id>
 5 ...
 6 </class>



如果主键属性不是对象型,而是基本类型,如int/long/double/...,那么你需要指定一个数值型的unsaved-value,例如:

java代码: 

 1 unsaved-null="0"



在此提醒大家,很多人以为对主键属性定义为int/long,比定义为Integer/Long运行效率来得高,认为基本类型不需要进行对象的封装和解构操作,因此喜欢把主键定义为int/long的。但实际上,Hibernate内部总是把主键转换为对象型进行操作的,就算你定义为int/long型的,Hibernate内部也要进行一次对象构造操作,返回给你的时候,还要进行解构操作,效率可能反而低也说不定。因此大家一定要扭转一个观点,在Hibernate中,主键属性定义为基本类型,并不能够比定义为对象型效率来的高,而且也多了很多麻烦,因此建议大家使用对象型的Integer/Long定义主键。

unsaved-value="none"和
unsaved-value="any"

主主要用在主键属性不是通过Hibernate生成,而是程序自己setId()的时候。

在这里多说一句,强烈建议使用Hibernate的id generator,或者你可以自己扩展Hibernate的id generator,特别注意不要使用有实际含义的字段当做主键来用!例如用户类User,很多人喜欢用用户登陆名称做为主键,这是一个很不好的习惯,当用户类和其他实体类有关联关系的时候,万一你需要修改用户登陆名称,一改就需要改好几张表中的数据。偶合性太高,而如果你使用无业务意义的id generator,那么修改用户名称,就只修改user表就行了。

由这个问题引申出来,如果你严格按照这个原则来设计数据库,那么你基本上是用不到手工来setId()的,你用Hibernate的id generator就OK了。因此你也不需要了解当

unsaved-value="none"和
unsaved-value="any"

究竟有什么含义了。如果你非要用assigned不可,那么继续解释一下:

unsaved-value="none" 的时候,由于不论主键属性为任何值,都不可能为none,因此Hibernate总是对child对象发送update(child)

unsaved-value="any" 的时候,由于不论主键属性为任何值,都肯定为any,因此Hibernate总是对child对象发送save(child)

大多数情况下,你可以避免使用assigned,只有当你使用复合主键的时候不得不手工setId(),这时候需要你自己考虑究竟怎么设置unsaved-value了,根据你自己的需要来定。

BTW: Gavin King强烈不建议使用composite-id,强烈建议使用UserType。

因此,如果你在系统设计的时候,遵循如下原则:

1、使用Hibernate的id generator来生成无业务意义的主键,不使用有业务含义的字段做主键,不使用assigned。

2、使用对象类型(String/Integer/Long/...)来做主键,而不使用基础类型(int/long/...)做主键

3、不使用composite-id来处理复合主键的情况,而使用UserType来处理该种情况。


那么你永远用的是unsaved-value="null" ,不可能用到any/none/..了。

posted @ 2006-03-02 20:45 killvin| 编辑 收藏

先来点概念:

在Hibernate中,最核心的概念就是对PO的状态管理。一个PO有三种状态:

1、未被持久化的VO
此时就是一个内存对象VO,由JVM管理生命周期

2、已被持久化的PO,并且在Session生命周期内
此时映射数据库数据,由数据库管理生命周期

3、曾被持久化过,但现在和Session已经detached了,以VO的身份在运行
这种和Session已经detached的PO还能够进入另一个Session,继续进行PO状态管理,此时它就成为PO的第二种状态了。这种PO实际上是跨了Session进行了状态维护的。

在传统的JDO1.x中,PO只有前面两种状态,一个PO一旦脱离PM,就丧失了状态了,不再和数据库数据关联,成为一个纯粹的内存VO,它即使进入一个新的PM,也不能恢复它的状态了。

Hibernate强的地方就在于,一个PO脱离Session之后,还能保持状态,再进入一个新的Session之后,就恢复状态管理的能力,但此时状态管理需要使用session.update或者session.saveOrUpdate,这就是Hibernate Reference中提到的“requires a slightly different programming model ”

现在正式进入本话题:

简单的来说,update和saveOrUpdate是用来对跨Session的PO进行状态管理的。

假设你的PO不需要跨Session的话,那么就不需要用到,例如你打开一个Session,对PO进行操作,然后关闭,之后这个PO你也不会再用到了,那么就不需要用update。

因此,我们来看看上例:
java代码: 

 1 Foo foo=sess.load(Foo.class,id);
 2 foo.setXXX(xxx);
 3 sess.flush();
 4 sess.commit();



PO对象foo的操作都在一个Session生命周期内完成,因此不需要显式的进行sess.update(foo)这样的操作。Hibernate会自动监测到foo对象已经被修改过,因此就向数据库发送一个update的sql。当然如果你非要加上sess.update(foo)也不会错,只不过这样做没有任何必要。

而跨Session的意思就是说这个PO对象在Session关闭之后,你还把它当做一个VO来用,后来你在Session外面又修改了它的属性,然后你又想打开一个Session,把VO的属性修改保存到数据库里面,那么你就需要用update了。

java代码: 

  // in the first session
  Cat cat = (Cat) firstSession.load(Cat.class, catId);
  Cat potentialMate = new Cat();
  firstSession.save(potentialMate);
  
  // in a higher tier of the application
  cat.setMate(potentialMate);
  
  // later, in a new session
 10 secondSession.update(cat)// update cat
 11 secondSession.update(mate); // update mate
 12 



cat和mate对象是在第一个session中取得的,在第一个session关闭之后,他们就成了PO的第三种状态,和Session已经detached的PO,此时他们的状态信息仍然被保留下来了。当他们进入第二个session之后,立刻就可以进行状态的更新。但是由于对cat的修改操作:cat.setMate(potentialMate); 是在Session外面进行的,Hibernate不可能知道cat对象已经被改过了,第二个Session并不知道这种修改,因此一定要显式的调用secondSession.update(cat); 通知Hibernate,cat对象已经修改了,你必须发送update的sql了。

所以update的作用就在于此,它只会被用于当一个PO对象跨Session进行状态同步的时候才需要写。而一个PO对象当它不需要跨Session进行状态管理的时候,是不需要写update的。

再谈谈saveOrUpdate的用场:

saveOrUpdate和update的区别就在于在跨Session的PO状态管理中,Hibernate对PO采取何种策略。

例如当你写一个DAOImpl的时候,让cat对象增加一个mate,如下定义:
java代码: 

1 public void addMate(Cat cat, Mate mate) {
 2     Session session = ...;
 3     Transacton tx = ...;
 4     session.update(cat);
 5     cat.addMate(mate);
 6     tx.commit();
 7     session.close();
 8 };



显然你是需要把Hibernate的操作封装在DAO里面的,让业务层的程序员和Web层的程序员不需要了解Hibernate,直接对DAO进行调用。

此时问题就来了:上面的代码运行正确有一个必要的前提,那就是方法调用参数cat对象必须是一个已经被持久化过的PO,也就是来说,它应该首先从数据库查询出来,然后才能这样用。但是业务层的程序员显然不知道这种内部的玄妙,如果他的业务是现在增加一个cat,然后再增加它的mate,他显然会这样调用,new一个cat对象出来,然后就addMate:

java代码: 

 1 Cat cat = new Cat();
 2 cat.setXXX();
 3 daoimpl.addMate(cat,mate);



但是请注意看,这个cat对象只是一个VO,它没有被持久化过,它还不是PO,它没有资格调用addMate方法,因此调用addMate方法不会真正往数据库里面发送update的sql,这个cat对象必须先被save到数据库,在真正成为一个PO之后,才具备addMate的资格。

你必须这样来操作:

java代码: 

 1 Cat cat = new Cat();
 2 cat.setXXX();
 3 daoimpl.addCat(cat);
 4 daoimpl.addMate(cat, mate);



先持久化cat,然后才能对cat进行其他的持久化操作。因此要求业务层的程序员必须清楚cat对象处于何种状态,到底是第一种,还是第三种。如果是第一种,就要先save,再addMate;如果是第三种,就直接addMate。

但是最致命的是,如果整个软件分层很多,业务层的程序员他拿到这个cat对象也可能是上层Web应用层传递过来的cat,他自己也不知道这个cat究竟是VO,没有被持久化过,还是已经被持久化过,那么他根本就没有办法写程序了。

所以这样的DAOImpl显然是有问题的,它会对业务层的程序员造成很多编程上的陷阱,业务层的程序员必须深刻的了解他调用的每个DAO对PO对象进行了何种状态管理,必须深刻的了解他的PO对象在任何时候处于什么确切的状态,才能保证编程的正确性,显然这是做不到的,但是有了saveOrUpdate,这些问题就迎刃而解了。

现在你需要修改addMate方法:

java代码: 

1 public void addMate(Cat cat, Mate mate) {
 2     Session session = ...;
 3     Transacton tx = ...;
 4     session.saveOrUpdate(cat);
 5     cat.addMate(mate);
 6     tx.commit();
 7     session.close();
 8 };



如上,如果业务层的程序员传进来的是一个已经持久化过的PO对象,那么Hibernate会更新cat对象(假设业务层的程序员在Session外面修改过cat的属性),如果传进来的是一个新new出来的对象,那么向数据库save这个PO对象。

BTW: Hibernate此时究竟采取更新cat对象,还是save cat对象,取决于unsave-value的设定。

这样,业务层的程序员就不必再操心PO的状态问题了,对于他们来说,不管cat是new出来的对象,只是一个VO也好;还是从数据库查询出来的的PO对象也好,全部都是直接addMate就OK了:

posted @ 2006-03-02 20:44 killvin| 编辑 收藏

今天同事问我Struts如何解决文件上传的问题,一时间没有想起来,就到google查了一下,果然在Struts Wiki上就有非常详细的解释,抄录如下,详细的请看(http://wiki.apache.org/struts/StrutsFileUpload)



StrutsFileUpload
File Upload - Simple Example
HTML
This isn't specific to Struts, but gives a simple example of the HTML required to upload a single file.

Two things are needed in the html page. Firstly, the form needs to specify an enctype of multipart/form-data and secondly an form control of type file.

JSP
The above HTML can be generated using the Struts tags in the following way

<html:form action="/uploadMyFile.do" enctype="multipart/form-data">

Select File: <html:file property="myFile">

<html:submit value="Upload File"/>

</html:form>

ActionForm
The ActionForm needs a property of type FormFile.

Regular ActionForms
import org.apache.struts.upload.FormFile;

public class MyActionForm extends ActionForm {

private FormFile myFile;

public void setMyFile(FormFile myFile) {
this.myFile = myfile;
}

public FormFile getMyFile() {
return myFile;
}
}

Dyna ActionForms
In the struts-config.xml

<form-bean name="myForm" type="org.apache.struts.action.DynaActionForm">
<form-property name="myFile" type="org.apache.struts.upload.FormFile"/>
</form-bean>

Whats Needed in the Action
Nothing special really, just retrieve the FormFile from the ActionForm, as you would any other property, and process it as you like. You can get the file name, size and file contents from the FormFile.

public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {

MyActionForm myForm = (MyActionForm)form;

// Process the FormFile
FormFile myFile = myForm.getMyFile();
String contentType = myFile.getContentType();
String fileName = myFile.getFileName();
int fileSize = myFile.getFileSize();
byte[] fileData = myFile.getFileData();
...
}

File Upload Configuration
The following parameters can be set in the <controller> element of the struts-config.xml to configure file upload:

bufferSize - The size (in bytes) of the input buffer used when processing file uploads. Default is 4096.

maxFileSize - The maximum size (in bytes) of a file to be accepted as a file upload. Can be expressed as a number followed by a "K", "M", or "G", which are interpreted to mean kilobytes, megabytes, or gigabytes, respectively. Default is 250M.

multipartClass - The fully qualified Java class name of the multipart request handler class to be used with this module. Defaults is org.apache.struts.upload.CommonsMultipartRequestHandler.

tempDir - Temporary working directory to use when processing file uploads.

Above taken from the Configuration section in the User Guide.

Plugging in an Alternative File Upload Mechanism
By default Struts uses Commons File Upload.

Alternative implementations can be plugged as long as they implement the org.apache.struts.upload.MultipartRequestHandler interface and Struts configured to use that implementation by specifying it in the multipartClass parameter in the <controller> element of the struts-config.xml

Fair Warning: The MultipartRequestHandler interface is almost certain to change in a Struts 1.3 or higher release.

posted @ 2006-03-02 20:43 killvin| 编辑 收藏

        以前总是认为php只是一种jsp的翻版,没有啥意思!不象J2EE的体系结构那样,有应用服务器的概念,只是一个简单的服务器脚本,而昨天的看法却让我大跌眼镜,其实php和java、python都处在一个层次上,甚至比java更有优势!不应该仅仅只是将php和jsp看作是同样的档次,这就好比是告诉写python的程序员,你们开发不了应用程序一样的让别人笑掉大牙,甚至怀疑你的脑子有毛病,zope就是一个很好的例子!!优秀的应用服务器,就是用Python开发的!
        
        我们更应该将php看作是一个语言,和python同样优秀(当然php和python的定位不同,也就是因为这样的定位,而让人产生的错觉!!)如果Php将自己定位如python一样!并在语言这个级别更贴近面向对象的思维模式,那Python也许就不会如此的火爆!
        
        看来php之父并没有将语言向python靠拢的意思,也就是说这样的语言目前的生存空间仅仅只限于服务器端的脚本!这是它的领地!但除非是它闭着眼镜,不然没有人会愿意看到html的代码里写这<?php>这样的代码!这就好比是在没有webwork 、struts这样优秀的web框架出现之前,jsp让人恶心的原因,如果Php的领域没有这样的MVC框架出现,那我情愿还是选择jsp!!出于学习我会选择Python,但永远不会选择php......
        
        告诉我你知道的php世界里优秀的web框架!也许我会改变看法!但我不会选择重新发明轮子!!

 

posted @ 2006-03-02 20:26 killvin| 编辑 收藏

Thinking in Python

You can download the current version of Thinking in Python here. This includes the BackTalk comment collection system that I built in Zope.

The page describing this project is here.

The current version of the book is 0.1. This is a preliminary release; please note that not all the chapters in the book have been translated.

The source code is in the download package. When you unzip everything (remember to use the -a flag if you're on Unix), the code will be put into subdirectories for each chapter.

This is not an introductory Python book. This book assumes you've learned the basics of Python elsewhere. I personally like Learning Python by Lutz & Ascher, from O'Reilly. Although it does not cover all the Python 2.0, 2.1 and 2.2 features that I use in this book, most books don't at this point.

However, Learning Python is not exactly a beginning programmer's book, either (although it's possible if you're dedicated). If you're just getting started with programming you might try the free, downloadable A Byte of Python.

posted @ 2006-03-02 20:23 killvin| 编辑 收藏

仅列出标题
共5页: 上一页 1 2 3 4 5 下一页