best_practices.po

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

"From time to time the Session synchronizes its persistent state with the "
"database. Performance will be affected if this process occurs too often. You "
"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が永続状態をデータベースと同期させることがときどきあります。 しかしこ"
"れがあまりに頻繁に起こるようだと、パフォーマンスに影響が出てきます。 自動フ"
"ラッシュを無効にしたり、特定のトランザクションのクエリや操作の順番を変更する"
"ことで、 不必要なフラッシュを最小限にできます。"

#. Tag: term
#: best_practices.xml:121
#, no-c-format
msgid "In a three tiered architecture, consider using detached objects."
msgstr "3層アーキテクチャでは分離オブジェクトの使用を考えましょう。"

#. 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 ""
"サーブレット / セッションビーンアーキテクチャを使うとき、 サーブレット層 / "
"JSP層間でセッションビーンでロードした永続オブジェクトをやり取りできます。 そ"
"の際リクエストごとに新しいSessionを使ってください。 また <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層アーキテクチャでは長い永続コンテキストの使用を考えましょう。"

#. 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> の実装が必要なことはしばしばです。 これはユーザの視点"
"からは1個の作業単位（unit of work）になります。 アプリケーショントランザク"
"ションはいくつかのクライアントのリクエスト/レスポンスサイクルにまたがりま"
"す。 アプリケーショントランザクションの実装に分離オブジェクトを使うのは一般的"
"です。 そうでなければ、2層アーキテクチャの場合は特に適切なことですが、 アプリ"
"ケーショントランザクションのライフサイクル全体に対して 単一のオープンな永続化"
"コンテキスト（セッション）を維持してください。 そして単純にリクエストの最後に"
"JDBCコネクションから切断し、 次のリクエストの最初に再接続します。 決して複数"
"のアプリケーショントランザクションユースケースに渡って 1個のSessionを使い回さ"
"ないでください。 そうでなければ、古いデータで作業することになります。"

#. 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 "関連にはなるべく遅延フェッチを使いましょう。"

#. 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 ""
"即時フェッチは控えめにしましょう。 二次キャッシュには完全に保持されないような"
"クラスの関連には、 プロキシと遅延コレクションを使ってください。 キャッシュさ"
"れるクラスの関連、つまりキャッシュがヒットする可能性が非常に高い関連は、 "
"<literal>lazy=\"false\"</literal> で積極的なフェッチを明示的に無効にしてくだ"
"さい。 結合フェッチが適切な特定のユースケースには、 クエリで <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は二つ目的がありま"
"す： 1つ目は、エンティティビーンがシリアライズされない問題への対策です。 2つ"
"目は、プレゼンテーション層に制御が戻る前に、 ビューに使われるすべてのデータが"
"フェッチされて、DTOに復元されるような組み立てフェーズを暗黙的に定義します。 "
"Hibernateでは1つ目の目的が不要になります。 しかしビューのレンダリング処理の"
"間、永続コンテキスト（セッション）をオープンにしたままにしなければ、 組み立て"
"フェーズはまだ必要です（分離オブジェクトの中のどのデータが利用可能かについ"
"て、 プレゼンテーション層と厳密な取り決めをしているビジネスメソッドを考えてみ"
"てください）。 これは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 ""
"よいユースケースに本当の多対多関連があることは稀（まれ）です。 ほとんどの場合"
"「リンクテーブル」の付加的な情報が必要になります。 この場合、リンククラスに2"
"つの1対多関連を使う方がずっと良いです。 実際ほとんどの場合関連は1対多と多対1"
"なので、 他のスタイルの関連を使うときは本当に必要かどうかを考えてみてくださ"
"い。"

#. 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 ""
"単方向関連は双方向に比べて検索が難しくなります。 大きなアプリケーションで"
"は、 ほとんどすべての関連が双方向にナビゲーションできなければなりません。"