인터셉터
인터셉터에 대해 말하면, 나는 Struts2에 익숙한 어린이 신발이 Struts2에 확실히 익숙하다고 생각합니다. Struts2는 인터셉터를 사용자 정의하여 원하는 일련의 관련 작업을 수행 할 수 있습니다. 그리고 우리가 여기서 이야기하는 인터셉터는 비슷한 기능을 가지고 있습니다.
말도 안되는 말을하지 않고 코드 만 말하십시오.
다음은 인터셉터 인터페이스를 구현하는 myinterceptor 클래스입니다.
공개 문자열 onpreparestatement (String arg0) {return arg0; } public boolean onsave (object arg0, serializable arg1, object [] arg2, string [] arg3, type [] arg4)는 callbackexception {if (arg0 instanceof user) {system.out.println ( "user to saved =>"+((user) arg0)); } false를 반환합니다. } 다른 방법을 읽지 않고 기본 구현을 따르십시오. 이 두 가지 방법 만 변경하면됩니다. 현재 SQL 문을 반환하려면 onpreparestatement의 반환 값을 변경해야합니다. 매개 변수는 통과 된 실행 된 SQL 문입니다. 직접 반환하여 명령문을 인쇄 할 수 있습니다.
OnSave에서는 저장할 때 호출된다고 말할 수 있습니다. 우리는 일련의 사전 보존 작업을 수행 할 수 있습니다.
나는 모든 사람이 매개 변수 이름을 보면 이해할 수 있다고 생각합니다.
직렬화 가능한 것은 시퀀스 번호의 매개 변수를 나타내며, 이는 데이터베이스 ID에 매핑되는 속성을 나타냅니다.
대상 [] 이것은 당분간 많이 사용되지 않은 일련의 상태입니다. 나중에 공부하겠습니다. 그러나 API는이 배열의 값이 어떻게 수정 되든 상관없이 온 사이트 메소드가 True를 반환해야한다고 설명합니다.
문자열 []는 속성의 이름을 나타냅니다. 유형 []는 해당 속성의 유형입니다.
1)이 인터셉터는 데이터베이스를 저장하기 전후에 해당 작업을 수행 할 수 있습니다. 예를 들어, 데이터를 수정하고 접두사 또는 접미사를 추가하려면이를 사용하여 구현할 수 있습니다. 아래를 살펴 보겠습니다.
public boolean onsave (object arg0, serializable arg1, object [] arg2, string [] arg3, type [] arg4)는 callbackexception {if (arg0 인스턴스 user) {system.out.println ( "user to saved =>"+((user) arg0)); } // 여기서 이름의 접두사로 123을 추가합니다. 사용자 user = (user) arg0; user.setName ( "123"+user.getName ()); 거짓을 반환합니다. }테스트 방법을 살펴 보겠습니다.
public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = CFG.BuildSessionFactory (); 인터셉터 인터셉터 = 새로운 myInteCeptor (); 세션 세션 = SessionFactory.opensession (인터셉터); 사용자 user = 새 사용자 (); user.setName ( "shun"); 트랜잭션 tx = session.begintransaction (); 세션 .SAVE (사용자); tx.commit (); session.close (); } 매우 간단합니다. 단순히 저장했습니다. 여기에는 매핑 파일과 엔티티 클래스가 없으며 시도해보십시오.
실행하면 다음을 볼 수 있습니다.
저장 할 사용자 => Shun Hibernate : user (user_name, age) 값 (?,?) hibernate에 삽입 : 사용자 세트 user_name =?, age =? 여기서 user_id =?그것은 결국 이름과 나이를 업데이트합니다. 주로 우리는 온 사이트 메소드를 변경했기 때문입니다.
public boolean onload (Object Arg0, Serializable Arg1, Object [] arg2, string [] arg3, type [] arg4) {if (arg0 instanceof user) {system.out.println ( "user holed =>"+(arg2 [0]+":"+arg2 [1]); } user user = (사용자) arg0; // 어떤 속성을 판단하는지 (int i = 0; i <arg3.length; i ++) {if (arg3 [i] .equals ( "name")) {user.setname ((string) arg2 [i]). Replare ( "123", ""); arg2 [i] = ((string) arg2 [i]). replare ( "123", ""); }} 거짓을 반환합니다. } 로드시 수정 된 속성의 값은 OnLoad 방법으로 작성됩니다.
여기서 ARG0은 사용자 객체입니다. 아직 가치가 없습니다. 이 방법은로드 메소드 후에 호출되므로 현재 사용자를 작동시키는 것은 쓸모가 없으며 user.setName은 쓸모없는 작업입니다. 주로 :
arg2 [i] = ((string) arg2 [i]). replare ( "123", "");
이 코드는 반환 된 속성의 값을 변경하므로 프로그램에서 얻는 사용자 객체의 값도 변경됩니다. 테스트 방법을 실행하겠습니다.
public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = CFG.BuildSessionFactory (); 인터셉터 인터셉터 = 새로운 myInteCeptor (); 세션 세션 = SessionFactory.opensession (인터셉터); 사용자 user = (user) session.load (user.class, new Long (39)); System.out.println ( "사용자 이름 :"+user.getName ()); session.close (); }결과를 살펴보면 다음과 같이 얻었습니다.
Hibernate : user0_0_0_, user2_0_0_, user2_0_0_, user0_.age as user0_0_ as user0_0_ as user0_.user_id를 선택하십시오. 로드 할 사용자 => 123shun : 0 사용자 이름 : Shun
우리는 원래 123을 제거하고 실제 로딩 후 관련 처리를 수행했지만 실제 로딩 이전의 실제 처리는 아니며 추측을 조금 의심합니다. 그러나 그것은 또한 고려 사항입니다. 인터셉터는 로그의 관련 처리에서 가장 많이 사용될 수 있습니다. 예를 들어, 각 작업에 따라 해당로 기록해야하므로 인터셉터가 좋은 선택입니다.
수집
이전 예제에서 우리가 일대일로 사용한 세트를 기억하십시오. 여전히 인상이 있습니까? 그렇지 않은 경우 정보를 확인하고 검토하십시오. 오늘 우리는이 컬렉션에 대해 배울 것입니다.
그냥 요점에 도달합시다.
1) 먼저 세트를 배우자. 모든 사람들은 Java Util 패키지에 세트가 있다는 것을 알고 있습니다. 그렇다면 최대 절전 모드에서 세트와 세트의 차이와 연결은 무엇입니까? 최대 절전 모드 API를 열고 설정을 찾으면 볼 수 있습니다.
우리가 보는 것은 그러한 최대 절전 모드 컬렉션의 부모 클래스입니다. 일련의 구체적인 구현 클래스가있는 추상 클래스입니다. 다음 방법을 계속 볼 때이 클래스는 Java 컬렉션의 캡슐화를 구현한다는 것을 알 수 있으므로 소위 최대 세트 세트가 실제로 Java 세트 만 캡슐화한다는 것을 이해합니다.
그렇다면이 특성은 최대 절전 모드에서 세트에서 중복 요소를 허용하지 않습니까? 대답은 물론 그렇습니다.
우리는 여기서 이것을 보지 않습니다. 과거에는 매핑을 배웠을 때, 우리는 속성을 관련 클래스와 직접 연관 시켰지만 오늘날 우리는 이렇습니다. 우리는 다른 방법을 사용합니다. 문제가 있는지 확인하기 위해 문자열을 연결합니다.
그러나이 질문을보기 전에 Java의 문자열 비교를 살펴 보겠습니다.
우리가 보는 것은 그러한 최대 절전 모드 컬렉션의 부모 클래스입니다. 일련의 구체적인 구현 클래스가있는 추상 클래스입니다. 다음 방법을 계속 볼 때이 클래스는 Java 컬렉션의 캡슐화를 구현한다는 것을 알 수 있으므로 소위 최대 세트 세트가 실제로 Java 세트 만 캡슐화한다는 것을 이해합니다.
그렇다면이 특성은 최대 절전 모드에서 세트에서 중복 요소를 허용하지 않습니까? 대답은 물론 그렇습니다.
우리는 여기서 이것을 보지 않습니다. 과거에는 매핑을 배웠을 때, 우리는 속성을 관련 클래스와 직접 연관 시켰지만 오늘날 우리는 이렇습니다. 우리는 다른 방법을 사용합니다. 문제가 있는지 확인하기 위해 문자열을 연결합니다.
그러나이 질문을보기 전에 Java의 문자열 비교를 살펴 보겠습니다.
public static void main (String [] args) {String s1 = "shun1"; 문자열 s2 = "shun1"; System.out.println ( "S1 == S2 :"+(S1 == S2)); } 나는 많은 어린이 신발이 그 대답이 사실이라는 것을 알고 있다고 생각합니다.
예를 들기 전에 매핑 파일을 살펴 보겠습니다. 우리는 매핑 클래스를 작성하지 않습니다.
이것은 Tuser의 매핑 파일입니다.
<class name = "tuser"table = "t_user"dynamic-Insert = "true"dynamic-update = "true"dynamic-update = "true"> <id name = "id"column = "id"> <generator/> </id> <속성 이름 = "name"type = "java.lang.string"column = "name"= "age ="java.nang " 열 = "age"/> <set name = "주소"cascade = "all"table = "t_address"> <key column = "user_id"/> <!-<one-to-many/>-> <요소 열 = "type"type = "string"/> </set> </class>
다음은 주소 매핑 파일입니다.
<class name = "address"table = "t_address"dynamic-Insert = "false"dynamic-update = "false"> <id name = "id"column = "id"type = "java.lang.integer"> <generator /> < /id> <property name = "wording"affeence "type" "java.lang.string". NOT-NULL = "true"> </ult-to-one> </class>
어린이 신발은 그것을 명확하게 보았습니다. 나는 니저와 중고 요소의 세트에서 일대일에 댓글을 달았습니다. 문제가 무엇이든 먼저 데이터베이스를 살펴 보겠습니다.
이것은 t_address 테이블입니다.
다음은 t_user 테이블입니다.
ID 4를 가진 사용자가 3 개의 주소에 해당하는 것을 볼 수 있습니다. 다음으로 테스트 방법을 살펴 보겠습니다.
public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = CFG.BuildSessionFactory (); 세션 세션 = sessionfactory.opensession (); Tuser user = (Tuser) Session.load (tuser.class, new Integer (4)); set set = user.getAddresses (); session.close (); System.out.println ( "주소 크기 :"+set.size ()); } 매우 간단한 쿼리 클래스, 방금이 결과를 얻었습니다. 우리는 이상한 현상을 보았습니다.
주소 크기 : 1
결과입니다!
당신은 확실히 말할 것입니다. 그것은 잘못되어야합니다. 그것은 최대 절전 모드의 버그입니다. 나는 여기서 행복해야한다. 마침내 버그를 제출할 수 있습니다. 작업을 전환했을 때, 나는 최대 절전 모드 버그를 제출했다고 큰 소리로 말할 수있었습니다. 하하, 그러나 불행히도 이것은 버그가 아닙니다.
방금 우리가 가진 끈의 비교가 여기에 길을 닦고 있다고 말했습니다. 그래서 그것을 포장하는 방법은 무엇입니까?
구성 파일에서 설정하고 문자열 문자를 통해 연결합니다. 그런 다음 데이터베이스에서 꺼내어 세트에 넣으면 먼저 관련 문자의 값이 동일한지 여부를 결정합니다. 여기서, 우리의 값은 동일하기 때문에 (우리는 그것이 당분간 비교하는 방식을 파지 않을 것입니다), 우리는 문자열을 비교할 때, 우리는 다시 Java의 스트링 트랩에 빠지는 것을 알아야합니다. 하나만 있다는 것을 알게되면 삭제할 때 삭제가 더 번거 롭게되면 동일한 레코드가 모두 삭제됩니다.
그런 다음 삭제 된 것을 살펴 보겠습니다.
Tuser user = (Tuser) Session.load (tuser.class, new Integer (4)); 트랜잭션 tx = session.begintransaction (); Object obj = user.getAddresses (). iterator (). next (); user.getAddresses (). 제거 (obj); tx.commit (); session.close ();
여기서 최대 절전 모드에 의한 진술 출력은 다음과 같습니다.
Hibernate : user_id = 어디에서 t_address에서 삭제하십시오.
나는 모든 사람들이 사용자 아래의 모든 주소를 삭제하는시기를 알고 있다고 생각합니다. 이 모든 것을 삭제하는 것 외에는 선택의 여지가 없습니다.
따라서 실제 개발에서주의를 기울여야합니다.
2) 우리는 위의 세트에 대해 이야기했는데, 사용하기가 그리 즐겁지 않은 것 같습니다. 그런 함정이 있지만 방법은 없습니다. 세트는 우리가 가장 많이 사용하는 것입니다. 일반적으로 아무도 문자열을 직접 연관시키지 않습니다. 그러나 많은 사람들이 여전히 불행하므로 최대 절전 모드는 필요에 따라 여분의 가방을 가질 것입니다 (아마도 필요하지 않을 수도 있습니다. 아마도 일부 사람들은 불만족 스럽습니다.
먼저 기본 사용법을 살펴 보겠습니다.
먼저 이전 턱시기 매핑 파일에서 세트 태그를 다음과 같이 수정해야합니다.
<bag name = "add
해당 엔티티 클래스는 주소 유형을 목록 유형으로 수정해야합니다.
여기에 세 가지 주소를 추가합니다.
테스트 코드를 실행합니다.
public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = CFG.BuildSessionFactory (); 세션 세션 = sessionfactory.opensession (); Tuser user = (Tuser) Session.load (tuser.class, new Integer (4)); System.out.println ( "주소 크기 :"+user.getAddresses (). size ()); session.close (); }
여기서 우리는 다음을 본다 :
주소 크기 : 3
이번에는 반복이 있는지 여부에 관계없이 모든 것을 볼 수 있습니다.
그러나 우리는 방금 삭제 문제를 보았습니다. 가방은 여기서 해결되지 않았으며 IDBag을 사용해야합니다. 구성 파일을보고 다음 수정이 필요합니다.
idbag name = "jand
우리는 그것이 삭제 될 레코드 번호를 나타 내기 위해 백보다 컬렉션 ID 만 더 가지고 있음을 알 수 있습니다.
삭제 된 코드를 다시 실행하면 :
Tuser user = (Tuser) Session.load (tuser.class, new Integer (4)); 트랜잭션 tx = session.begintransaction (); Object obj = user.getAddresses (). iterator (). next (); user.getAddresses (). 제거 (obj); tx.commit ();
출력 문은 다음과 같습니다.
Hibernate : id =?에서 t_address에서 삭제하십시오.
이번에는 user_id를 통해 삭제되지는 않지만 t_address의 ID를 기반으로 삭제 해야하는 레코드를 실제로 삭제합니다.
우리는 데이터베이스를보고 레코드는 이제 다음과 같습니다.
우리는 첫 번째 레코드를 삭제했습니다. 맞습니다.
3) 위의 두 가지 방법을 살펴본 후지도를 살펴 보겠습니다. 그것과 위의 두 가지의 가장 큰 차이점은 키 값에 해당 할 수 있다는 것입니다. 직관적 인 관점을 직접 살펴보십시오.
먼저 구성 파일을 수정해야합니다.
<map name = "add
IT와 이전 두 가지의 가장 큰 차이점은 Java의 MAP 키와 동등한 인덱스가 있다는 것입니다.이를 사용하여 해당 레코드를 검색합니다. 여기에서 변경 한 후에는 해당 엔티티 클래스를 변경해야하며 주소 속성의 유형을지도로 변경해야합니다.
데이터베이스 데이터를보십시오.
여기에 우리는 두 개의 사무실과 1 개의 주택이 있다는 것을 알 수 있습니다. 그래서 어떤 사무실을 사용해야합니까?
걱정하지 마십시오. 테스트 코드를 실행 한 후 알게 될 것입니다.
Tuser user = (Tuser) Session.load (tuser.class, new Integer (4)); System.out.println (user.getAddresses (). get ( "home")); System.out.println (user.getAddresses (). get ( "Office"));
Shanwei 상하이
예, 결과에서 알 수 있듯이, 우리는 뒤에있는 것을 얻습니다. 이것은지도의 원리와 동일합니다. 저장된 값은 이전 값을 덮어 씁니다 (동일한 키 인 경우).
맵은 비교적 간단하며 처음 두 가지와 비슷합니다.
4) 마지막 것을 살펴 보겠습니다. 목록은 이전의 목록과 다르며 정렬 할 수 있습니다.
구현 방법을 살펴 보겠습니다.
먼저 매핑 파일을 수정하겠습니다.
<list name = "add
맵 구성과 유사하지만 색인의 속성은 다릅니다. 맵의 인덱스는 값을 얻기위한 키로 사용되며 목록의 인덱스는 정렬로 사용됩니다.
데이터베이스를 살펴 보겠습니다.
우리는 0, 1 및 2의 순서로 세 가지 값을 설정합니다.
0과 2의 값을 변경하기 위해 코드를 실행합시다.
Tuser user = (Tuser) Session.load (tuser.class, new Integer (4)); 트랜잭션 tx = session.begintransaction (); Object obj1 = user.getAddresses (). get (0); Object obj2 = user.getAddresses (). get (2); user.getAddresses (). set (0, obj2); user.getAddresses (). set (2, obj1); tx.commit ();
우리는 결과를 본다 :
우리는 0과 2가 대체되었으며 물론 이것은 IDX의 값을 바꾸는 것입니다. 그러나 이것은 기본적으로 분류 기능을 구현했습니다.