best_practices.po

hibernate 开源框架的代码 jar包希望大家能喜欢

"may 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
#: best_practices.xml:121
#, no-c-format
msgid "In a three tiered architecture, consider using detached objects."
msgstr ""
"3-tier 아키텍처에서, <literal>saveOrUpdate()</literal> 사용을 고려하라."

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

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

#. Tag: para
#: best_practices.xml:134
#, no-c-format
msgid ""
"Database Transactions have to be as short as possible for best scalability. "
"However, it is often neccessary to implement long running "
"<emphasis>application transactions</emphasis>, 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 alternative, extremely appropriate in "
"two tiered architecture, is to maintain a single open persistence contact "
"(session) for the whole life cycle of the application transaction and 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>어플리케이션 트랜잭션들</emphasis>, 사용자의 뷰 관"
"점에서 한 개의 단위 작업을 구현하는 것이 가끔 필수적이다. 하나의 어플리케이"
"션 트랜잭션은 몇 개의 클라이언트 요청들과 응답 주기들에 걸칠 수도 있다. 어플"
"리케이션 트랜잭션들을 구현하는데 detached 객체들을 사용하는 것이 공통적이다. "
"2-티어 아키텍처에서 매우 적절한 대안은 어플리케이션 트랜잭션의 전체 생명주기 "
"동안에 한 개의 열려진 영속 접속 (세션)을 유지하는 것이고 각각의 요청의 끝에"
"서 JDBC 커넥션을 간단하게 연결해제하고 차후의 요청의 시작 시에 다시 연결하는 "
"것이다. 한 개 이상의 어플리케이션 트랜잭션을 가로질러서 하나의 단일 세션을 결"
"코 공유하지 말라. 공유할 경우에 당신은 실효성이 없는 데이터로 작업하게 될 것"
"이다."

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

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

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

#. Tag: para
#: best_practices.xml:162
#, 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\"</literal>. When an join fetching is "
"appropriate to a particular use case, use a query with a <literal>left join "
"fetch</literal>."
msgstr ""
"eager 페칭을 관대하게 사용하라. second-level 캐시 내에 완전하게 보관되지 않"
"을 것 같은 클래스들에 대한 대붑분의 연관들에 대해 프락시들과 lazy 콜렉션들을 "
"사용하라. 캐시된 클래스들에 대한 연관들의 경우, 이곳은 캐시 성공의 매우 높은 "
"확률이 존재하는 곳이며, <literal>lazy=\"false\"</literal>를 사용하여 eager 페"
"칭을 명시적으로 사용 불가능하게 하라. 한의 join 페칭이 특정 쓰임새에 대해 적"
"절할 때, 하나의 <literal>left join fetch</literal>를 가진 질의를 사용하라."

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

#. Tag: para
#: best_practices.xml:177
#, 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. However, 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) unless you are "
"prepared to hold the persistence context (the session) open across the view "
"rendering process. This is not a limitation of Hibernate! It is a "
"fundamental requirement of safe transactional data access."
msgstr ""
"Hibernate는 개발자들이 <emphasis>Data Transfer Objects</emphasis> (DTO)를 지"
"루하게 작성하는 것으로부터 자유롭게 해준다. 전통적인 EJB 아키텍처에서, DTO는 "
"이중 용도로 기능한다: 첫 번째로 그것들은 엔티티 빈즈가 직렬화 가능하지 않는 "
"문제점에 대해 착수한다; 두 번째로 그것들은 뷰에 의해 사용되는 모든 데이터가 "
"프리젠테이션 티어로 컨트롤을 반환하기 전에 DTO들 속으로 페치되고 마샬링되는 "
"어셈블리 단계를 암묵적으로 정의한다. Hibernate는 첫 번째 용도를 제거시킨다. "
"하지만 당신이 뷰 렌더링 프로세스를 가로질러 열려져 있는 영속 컨텍스트(세션)"
"을 보관할 준비가 되어 있지 않는 한, 당신은 여전히 어셈블리 단계를 필요로 할 "
"것이다(detached 객체들에서 이용가능한 데이터가 무엇인지에 대해 프리젠테이션 "
"티어와 엄격하게 계약을 갖도록 당신의 비지니스 메소드들을 고려하라) 이것은 "
"Hibernate의 한계점이 아니다! 그것은 안전한 트랜잭션 데이터 접근의 필수 조건이"
"다."

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

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

#. Tag: term
#: best_practices.xml:203
#, no-c-format
msgid "Don't use exotic association mappings."
msgstr "신종의 연관 매핑을 사용하지 말라."

#. Tag: para
#: best_practices.xml:205
#, no-c-format
msgid ""
"Good usecases for a 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, we think that most associations are one-to-"
"many and many-to-one, you should be careful when using any other association "
"style and ask yourself if it is really neccessary."
msgstr ""
"실제의 many-to-many 연관들에 대한 좋은 쓰임새들은 드물다. 대부분의 시간 동안 "
"당신은 \"연결 테이블\" 내에 저장된 추가적인 정보를 필요로 한다. 이 경우에, 매"
"개하는 연결 클래스에 대해 두 개의 one-to-many 연관들을 사용하는 것이 훨씬 더 "
"좋다. 사실 우리는 대부분의 연관들이 one-to-many와 many-to-one이라고 생각하"
"며, 당신은 다른 연관 스타일을 사용할 때 주의해야 하고 그것이 진정 필수적인지"
"를 당신 스스로 질문하라."

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

#. Tag: para
#: best_practices.xml:217
#, 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 ""
"단방향 연관들은 질의하기가 더 어렵다. 많은 어플리케이션에서, 거의 모든 연관들"
"은 질의들 내에서 양 방향으로 네비게이트 가능해야 한다."