Hibernate example source code file (best_practices.po)

This example Hibernate source code file (best_practices.po) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" ^TM.

Java - Hibernate tags/keywords

do, dto, hibernate, hibernate, in, jdbc, jdbc, session, tag, tag, this, this, use, you

The Hibernate best_practices.po source code

msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2010-02-11T05:38:15\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#, no-c-format
msgid "Best Practices"
msgstr "최상의 실전 경험들"

#. Tag: term
#, fuzzy, no-c-format
msgid ""
"Write fine-grained classes and map them using <literal><component>를 사용"
"하여 그것들을 매핑하라."

#. Tag: para
#, no-c-format
msgid ""
"Use an <literal>Address class to encapsulate streetsuburb, state, "
"<literal>postcode. This encourages code reuse and simplifies "
"refactoring."
msgstr ""
"<literal>street, suburb, statepostcode를 캡슐화 시키는데 Addressequals() and "
"<literal>hashCode() to compare the properties that make up the "
"natural key."
msgstr ""
"모든 엔티티들에 대해 고유 키들을 식별하고, <literal><natural-id>와 hashCode()를 구현하"
"라."

#. Tag: term
#, fuzzy, no-c-format
msgid "Place each class mapping in its own file:"
msgstr "각각의 클래스 매핑을 그것 자신의 파일 내에 위치지워라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Do not use a single monolithic mapping document. Map <literal>com.eg.Foocom/eg/Foo.hbm.xml. This makes "
"sense, particularly in a team environment."
msgstr ""
"하나의 한덩어리 매핑 문서를 사용하지 말라. <literal>com/eg/Foo.hbm.xmlcom.eg.Foo를 매핑하라. 이것은 팀 환경에"
"서 특히 좋은 의미를 준다."

#. Tag: term
#, fuzzy, no-c-format
msgid "Load mappings as resources:"
msgstr "매핑들을 리소스들로서 로드시켜라."

#. Tag: para
#, no-c-format
msgid "Deploy the mappings along with the classes they map."
msgstr "그것들이 매핑하는 클래스들에 따라서 매핑들을 배치하라"

#. Tag: term
#, fuzzy, no-c-format
msgid "Consider externalizing query strings:"
msgstr "질의 문자열들을 객관화 시키는 것을 고려하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This is recommended if your queries call non-ANSI-standard SQL functions. "
"Externalizing the query strings to mapping files will make the application "
"more portable."
msgstr ""
"당신의 질의들이 ANSI 표준이 아닌 SQL 함수들을 호출하는 경우는 좋은 실전연습이"
"다. 질의 문자열들을 매핑 파일들에다가 외부화 시키는 것은 어플리케이션을 보다 "
"이식성 있도록 만들어줄 것이다."

#. Tag: term
#, no-c-format
msgid "Use bind variables."
msgstr "바인드 변수들을 사용하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"As in JDBC, always replace non-constant values by \"?\". Do not use string "
"manipulation to bind a non-constant value in a query. You should also "
"consider using named parameters in queries."
msgstr ""
"JDBC에서처럼, 상수 아닌 값들을 \"?\"로 대체시켜라. 질의 속에 상수 아닌 값을 "
"바인드 시키는데 문자열 처리를 결코 사용하지 말라! 더 좋게는 질의들 속에 명명"
"된 파라미터들을 사용하는 것을 고려하라."

#. Tag: term
#, fuzzy, no-c-format
msgid "Do not manage your own JDBC connections:"
msgstr "당신 자신의 JDBC 커넥션들을 관리하지 말라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate allows the application to manage JDBC connections, but his "
"approach should be considered a last-resort. If you cannot use the built-in "
"connection providers, consider providing your own implementation of "
"<literal>org.hibernate.connection.ConnectionProvider."
msgstr ""
"Hibernate는 어플리케이션으로 하여금 JDBC 커넥션들을 관리하도록 한다. 이 접근"
"법은 마지막 수단으로서 고려되어야 한다. 만일 당신이 미리 만들어진 커넥션 프로"
"바이더들을 사용할 수 없을 경우, <literal>org.hibernate.connection."
"ConnectionProvider</literal>에 대한 당신 자신의 구현을 제공하는 것을 고려하"
"라."

#. Tag: term
#, fuzzy, no-c-format
msgid "Consider using a custom type:"
msgstr "맞춤형 타입 사용을 고려하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Suppose you have a Java type from a library that needs to be persisted but "
"does not provide the accessors needed to map it as a component. You should "
"consider implementing <literal>org.hibernate.UserType. This "
"approach frees the application code from implementing transformations to/"
"from a Hibernate type."
msgstr ""
"당신이 자바 타입을 갖고 있고, 어떤 라이브러리로부터 말하고, 그것이 영속화 될 "
"필요가 있지만 그것을 컴포넌트로서 매핑시키는데 필요한 accessor들을 제공할 필"
"요가 없다고 가정하자. 당신은 <literal>org.hibernate.UserType을 구현"
"하는 것을 고려해야 할 것이다. 이 접근법은 Hibernate 타입으로/으로부터 변환들"
"을 구현하는 것으로부터 어플리케이션 코드를 자유롭게 해준다."

#. Tag: term
#, fuzzy, no-c-format
msgid "Use hand-coded JDBC in bottlenecks:"
msgstr "병목 지점들에서 수작업으로 코딩된 JDBC를 사용하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In performance-critical areas of the system, some kinds of operations might "
"benefit from direct JDBC. Do not assume, however, that JDBC is necessarily "
"faster. Please wait until you <emphasis>know something is a "
"bottleneck. If you need to use direct JDBC, you can open a Hibernate "
"<literal>Session, wrap your JDBC operation as a org."
"hibernate.jdbc.Work</literal> object and using that JDBC connection. This "
"way you can still use the same transaction strategy and underlying "
"connection provider."
msgstr ""
"시스템의 퍼포먼스가 중대한 영역들에서, 몇몇 종류의 오퍼레이션들은 직접적인 "
"JDBC에서 이득을 본다. 그러나 당신이 어떤 것이 병목인지를 <emphasis>알기을 열고 그 SQL 커넥션을 사용할 가치가 있"
"다. 그 방법으로 당신은 동일한 트랜잭션 방도와 기본 커넥션 프로바이더를 여전"
"히 사용할 수 있다"

#. Tag: term
#, fuzzy, no-c-format
msgid "Understand <literal>Session flushing:"
msgstr "<literal>Session flushing을 이해하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Sometimes the Session synchronizes its persistent state with the database. "
"Performance will be affected if this process occurs too often. You can "
"sometimes minimize unnecessary flushing by disabling automatic flushing, or "
"even by changing the order of queries and other operations within a "
"particular transaction."
msgstr ""
"시간이 지남에 따라 Session은 그것의 영속 상태를 데이터베이스와 동기화 시킨"
"다. 만일 이 과정이 너무 자주 발생할 경우 퍼포먼스가 영향을 받을 것이다. 당신"
"은 때때로 자동적인 flushing을 사용 불가능하게 만들거나 특정 트랜잭션 내에서 "
"질의들의 순서와 다른 오퍼레이션들의 순서를 변경시켜서 불필요한 flushing을 최"
"소화 시킬 수 있다."

#. Tag: term
#, fuzzy, no-c-format
msgid "In a three tiered architecture, consider using detached objects:"
msgstr ""
"3-tier 아키텍처에서, <literal>saveOrUpdate() 사용을 고려하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"When using a servlet/session bean architecture, you can pass persistent "
"objects loaded in the session bean to and from the servlet/JSP layer. Use a "
"new session to service each request. Use <literal>Session.merge() "
"or <literal>Session.saveOrUpdate() to synchronize objects with the "
"database."
msgstr ""
"servlet / session 빈 아키텍처를 사용할 때, 당신은 sesson bean 내에 로드된 영"
"속 객체들을 서블릿/JSP 계층으로/으로부터 전달할/받을 수 있다. 각각의 요청을 "
"서비스하는데 새로운 세션을 사용하라. 객체들을 데이터베이스와 동기화 시키기 위"
"해서 <literal>Session.merge() 또는 Session.saveOrUpdate()"
"</literal>를 사용하라."

#. Tag: term
#, fuzzy, no-c-format
msgid "In a two tiered architecture, consider using long persistence contexts:"
msgstr ""
"2-tier 아키텍처에서, 수명이 긴 영속 컨텍스트들을 사용하는 것을 고려하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Database Transactions have to be as short as possible for best scalability. "
"However, it is often necessary to implement long running "
"<emphasis>application transactions, a single unit-of-work from "
"the point of view of a user. An application transaction might span several "
"client request/response cycles. It is common to use detached objects to "
"implement application transactions. An appropriate alternative in a two "
"tiered architecture, is to maintain a single open persistence contact "
"session for the whole life cycle of the application transaction. Then simply "
"disconnect from the JDBC connection at the end of each request and reconnect "
"at the beginning of the subsequent request. Never share a single session "
"across more than one application transaction or you will be working with "
"stale data."
msgstr ""
"데이터베이스 트랜잭션들은 최상의 가용성을 위해 가능한 한 짧아야 한다. 하지만 "
"장기간 실행되는 <emphasis>어플리케이션 트랜잭션들, 사용자의 뷰 관"
"점에서 한 개의 단위 작업을 구현하는 것이 가끔 필수적이다. 하나의 어플리케이"
"션 트랜잭션은 몇 개의 클라이언트 요청들과 응답 주기들에 걸칠 수도 있다. 어플"
"리케이션 트랜잭션들을 구현하는데 detached 객체들을 사용하는 것이 공통적이다. "
"2-티어 아키텍처에서 매우 적절한 대안은 어플리케이션 트랜잭션의 전체 생명주기 "
"동안에 한 개의 열려진 영속 접속 (세션)을 유지하는 것이고 각각의 요청의 끝에"
"서 JDBC 커넥션을 간단하게 연결해제하고 차후의 요청의 시작 시에 다시 연결하는 "
"것이다. 한 개 이상의 어플리케이션 트랜잭션을 가로질러서 하나의 단일 세션을 결"
"코 공유하지 말라. 공유할 경우에 당신은 실효성이 없는 데이터로 작업하게 될 것"
"이다."

#. Tag: term
#, fuzzy, no-c-format
msgid "Do not treat exceptions as recoverable:"
msgstr "예외상황들을 복구가능한 것으로서 다루지 말라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This is more of a necessary practice than a \"best\" practice. When an "
"exception occurs, roll back the <literal>Transaction and close the "
"<literal>Session. If you do not do this, Hibernate cannot "
"guarantee that in-memory state accurately represents the persistent state. "
"For example, do not use <literal>Session.load() to determine if an "
"instance with the given identifier exists on the database; use "
"<literal>Session.get() or a query instead."
msgstr ""
"이것은 \"최상의\" 실전이 아닌 보다 필수적인 실전이다. 예외상황이 발생할 때, "
"<literal>Transaction을 롤백시키고 Session을 닫아"
"라. 만일 당신이 그렇게 하지 않을 경우, Hibernate는 메모리 내 상태가 영속 상태"
"를 정확하게 표현하는 것을 보증할 수 없다. 이 특별한 경우처럼, 만일 주어진 식"
"별자를 가진 인스턴스가 데이터베이스 상에 존재하는지 여부를 결정하는데 "
"<literal>Session.load()를 사용하지 말라; 대신에 Session."
"get()</literal> 또는 하나의 질의를 사용하라."

#. Tag: term
#, fuzzy, no-c-format
msgid "Prefer lazy fetching for associations:"
msgstr "연관들에 대한 lazy 페칭을 선호하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Use eager fetching sparingly. Use proxies and lazy collections for most "
"associations to classes that are not likely to be completely held in the "
"second-level cache. For associations to cached classes, where there is an a "
"extremely high probability of a cache hit, explicitly disable eager fetching "
"using <literal>lazy=\"false\". When join fetching is appropriate "
"to a particular use case, use a query with a <literal>left join fetch를 사용하여 eager 페"
"칭을 명시적으로 사용 불가능하게 하라. 한의 join 페칭이 특정 쓰임새에 대해 적"
"절할 때, 하나의 <literal>left join fetch를 가진 질의를 사용하라."

#. Tag: term
#, fuzzy, no-c-format
msgid ""
"Use the <emphasis>open session in view pattern, or a disciplined "
"<emphasis>assembly phase to avoid problems with unfetched data:"
msgstr ""
"페치되지 않은 데이터 문제점들을 피하기 위해 <emphasis>뷰 내에 열려진 세션"
"(open session in view)</emphasis> 패턴 또는 하나의 정리된 어셈블리 "
"단계(assembly phase)</emphasis>를 사용하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate frees the developer from writing tedious <emphasis>Data Transfer "
"Objects</emphasis> (DTO). In a traditional EJB architecture, DTOs serve dual "
"purposes: first, they work around the problem that entity beans are not "
"serializable; second, they implicitly define an assembly phase where all "
"data to be used by the view is fetched and marshalled into the DTOs before "
"returning control to the presentation tier. Hibernate eliminates the first "
"purpose. Unless you are prepared to hold the persistence context (the "
"session) open across the view rendering process, you will still need an "
"assembly phase. Think of your business methods as having a strict contract "
"with the presentation tier about what data is available in the detached "
"objects. This is not a limitation of Hibernate. It is a fundamental "
"requirement of safe transactional data access."
msgstr ""
"Hibernate는 개발자들이 <emphasis>Data Transfer Objects (DTO)를 지"
"루하게 작성하는 것으로부터 자유롭게 해준다. 전통적인 EJB 아키텍처에서, DTO는 "
"이중 용도로 기능한다: 첫 번째로 그것들은 엔티티 빈즈가 직렬화 가능하지 않는 "
"문제점에 대해 착수한다; 두 번째로 그것들은 뷰에 의해 사용되는 모든 데이터가 "
"프리젠테이션 티어로 컨트롤을 반환하기 전에 DTO들 속으로 페치되고 마샬링되는 "
"어셈블리 단계를 암묵적으로 정의한다. Hibernate는 첫 번째 용도를 제거시킨다. "
"하지만 당신이 뷰 렌더링 프로세스를 가로질러 열려져 있는 영속 컨텍스트(세션)"
"을 보관할 준비가 되어 있지 않는 한, 당신은 여전히 어셈블리 단계를 필요로 할 "
"것이다(detached 객체들에서 이용가능한 데이터가 무엇인지에 대해 프리젠테이션 "
"티어와 엄격하게 계약을 갖도록 당신의 비지니스 메소드들을 고려하라) 이것은 "
"Hibernate의 한계점이 아니다! 그것은 안전한 트랜잭션 데이터 접근의 필수 조건이"
"다."

#. Tag: term
#, fuzzy, no-c-format
msgid "Consider abstracting your business logic from Hibernate:"
msgstr "Hibernate에서 당신의 비지니스 로직을 추상화 시키는 것을 고려하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hide Hibernate data-access code behind an interface. Combine the "
"<emphasis>DAO and Thread Local Session "
"patterns. You can even have some classes persisted by handcoded JDBC "
"associated to Hibernate via a <literal>UserType. This advice is, "
"however, intended for \"sufficiently large\" applications. It is not "
"appropriate for an application with five tables."
msgstr ""
"(Hibernate) 데이터 액세스 코드를 인터페이스 이면에 은폐시켜라. "
"<emphasis>DAO와 Thread Local Session 패턴들"
"을 결합시켜라. 당신은 심지어 <literal>UserType을 통해 Hibernate에 "
"연관된, 수작업으로 코딩된 JDBC로서 몇몇 클래스들을 영속화 시킬 수도 있다. "
"(이 충고는 \"충분히 큰\" 어플리케이션들에 대한 것이다; 그것은 5개의 테이블들"
"을 가진 어플리케이션에 대해서는 적절하지 않다!)"

#. Tag: term
#, fuzzy, no-c-format
msgid "Do not use exotic association mappings:"
msgstr "신종의 연관 매핑을 사용하지 말라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Practical test cases for real many-to-many associations are rare. Most of "
"the time you need additional information stored in the \"link table\". In "
"this case, it is much better to use two one-to-many associations to an "
"intermediate link class. In fact, most associations are one-to-many and many-"
"to-one. For this reason, you should proceed cautiously when using any other "
"association style."
msgstr ""
"실제의 many-to-many 연관들에 대한 좋은 쓰임새들은 드물다. 대부분의 시간 동안 "
"당신은 \"연결 테이블\" 내에 저장된 추가적인 정보를 필요로 한다. 이 경우에, 매"
"개하는 연결 클래스에 대해 두 개의 one-to-many 연관들을 사용하는 것이 훨씬 더 "
"좋다. 사실 우리는 대부분의 연관들이 one-to-many와 many-to-one이라고 생각하"
"며, 당신은 다른 연관 스타일을 사용할 때 주의해야 하고 그것이 진정 필수적인지"
"를 당신 스스로 질문하라."

#. Tag: term
#, fuzzy, no-c-format
msgid "Prefer bidirectional associations:"
msgstr "양방향 연관들을 선호하라."

#. Tag: para
#, no-c-format
msgid ""
"Unidirectional associations are more difficult to query. In a large "
"application, almost all associations must be navigable in both directions in "
"queries."
msgstr ""
"단방향 연관들은 질의하기가 더 어렵다. 많은 어플리케이션에서, 거의 모든 연관들"
"은 질의들 내에서 양 방향으로 네비게이트 가능해야 한다."