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

# translation of Collection_Mapping.po to
# Xi HUANG <xhuang@redhat.com>, 2007, 2010.
msgid ""
msgstr ""
"Project-Id-Version: Collection_Mapping\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2010-02-11T05:38:15\n"
"PO-Revision-Date: 2010-01-20 16:59+1000\n"
"Last-Translator: Xi HUANG <xhuang@redhat.com>\n"
"Language-Team:  <en@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"

#. Tag: title
#, no-c-format
msgid "Best Practices"
msgstr "ベストプラクティス"

#. Tag: term
#, 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 （都市）、 "
"<literal>state （州）、 postcode （郵便番号）を"
"カプセル化する <literal>Address （住所）クラスを使いましょう。そう"
"すればコードが再利用しやすくなり、リファクタリングも簡単になります。"

#. Tag: term
#, no-c-format
msgid "Declare identifier properties on persistent classes:"
msgstr "永続クラスには識別子プロパティを定義しましょう。"

#. Tag: para
#, no-c-format
msgid ""
"Hibernate makes identifier properties optional. There are a range of reasons "
"why you should use them. We recommend that identifiers be 'synthetic', that "
"is, generated with no business meaning."
msgstr ""
"Hibernate では識別子プロパティはオプションですが、使用すべき理由がたくさんあ"
"ります。識別子は「人工的」（生成された、業務的な意味を持たない）なものにする"
"ことをおすすめします。"

#. Tag: term
#, no-c-format
msgid "Identify natural keys:"
msgstr "自然キーを見つけましょう。"

#. Tag: para
#, no-c-format
msgid ""
"Identify natural keys for all entities, and map them using <literal><"
"natural-id></literal>. Implement equals() and "
"<literal>hashCode() to compare the properties that make up the "
"natural key."
msgstr ""
"すべてのエンティティに対して自然キーを見つけて、 <literal><natural-id>"
"</literal> でマッピングしましょう。自然キーを構成するプロパティを比較するため"
"に、 <literal>equals() と hashCode() を実装しま"
"しょう。"

#. Tag: term
#, no-c-format
msgid "Place each class mapping in its own file:"
msgstr "クラスのマッピングはそれぞれのクラス専用のファイルに書きましょう。"

#. Tag: para
#, 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</literal> クラスなら com/eg/Foo.hbm.xml ファイルにマッ"
"ピングしましょう。このことは、特にチームでの開発に意味があります。"

#. Tag: term
#, 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
#, no-c-format
msgid "Consider externalizing query strings:"
msgstr "クエリ文字列を外部に置くことを考えましょう"

#. Tag: para
#, 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
#, 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
#, no-c-format
msgid "Do not manage your own JDBC connections:"
msgstr "JDBC コネクションを管理してはいけません。"

#. Tag: para
#, 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
#, no-c-format
msgid "Consider using a custom type:"
msgstr "カスタム型の使用を考えましょう。"

#. Tag: para
#, 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 ""
"あるライブラリから持ってきた Java 型を永続化する必要があるとしましょう。しか"
"しその型には、コンポーネントとしてマッピングするために必要なアクセサがないと"
"します。このような場合は <literal>org.hibernate.UserType の実装を考"
"えるべきです。そうすれば Hibernate 型との実装変換を心配せずにアプリケーション"
"のコードを扱えます。"

#. Tag: term
#, 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>はっき"
"りする</emphasis> までは待ってください。また JDBC を直接使うからといって、必"
"ずしも速くなるとは限らないことも理解してください。 JDBC を直接使う必要があれ"
"ば、 Hibernate の <literal>Session をオープンして、  JDBC コネク"
"ションを使うと良いかもしれません。依然として同じトランザクション戦略とコネク"
"ションプロバイダが使えるからです。"

#. Tag: term
#, no-c-format
msgid "Understand <literal>Session flushing:"
msgstr "<literal>Session のフラッシュを理解しましょう。"

#. Tag: para
#, 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 が永続状態をデータベースと同期させることがときどきあります。しかしこ"
"れがあまりに頻繁に起こるようだと、パフォーマンスに影響が出てきます。自動フ"
"ラッシュを無効にしたり、特定のトランザクションのクエリや操作の順番を変更する"
"ことで、不必要なフラッシュを最小限にできます。"

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

#. Tag: para
#, 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 ""
"サーブレット / セッション Bean アーキテクチャを使うとき、サーブレット層 / "
"JSP 層間でセッション Bean でロードした永続オブジェクトをやり取りできます。そ"
"の際リクエストごとに新しい Session を使ってください。また <literal>Session."
"merge()</literal> や Session.saveOrUpdate() を使って、オブ"
"ジェクトとデータベースを同期させてください。"

#. Tag: term
#, no-c-format
msgid "In a two tiered architecture, consider using long persistence contexts:"
msgstr "2層アーキテクチャでは長い永続コンテキストの使用を考えましょう。"

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

#. Tag: term
#, no-c-format
msgid "Do not treat exceptions as recoverable:"
msgstr "例外を復帰可能なものとして扱ってはいけません。"

#. Tag: para
#, 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 を使うことはやめてください。その代わりに "
"<literal>Session.get() かクエリを使ってください。"

#. Tag: term
#, no-c-format
msgid "Prefer lazy fetching for associations:"
msgstr "関連にはなるべく遅延フェッチを使いましょう。"

#. Tag: para
#, 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 で積極的なフェッチを明示的に無効にしてくだ"
"さい。結合フェッチが適切な特定のユースケースには、クエリで <literal>left "
"join fetch</literal> を使ってください。"

#. Tag: term
#, 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> パターンか、統制"
"された <emphasis>組み立てフェーズ (assembly phase)  を使いましょ"
"う。"

#. Tag: para
#, 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 は2つ目的があり"
"ます： 1つ目は、エンティティ Bean がシリアライズされない問題への対策です。2つ"
"目は、プレゼンテーション層に制御が戻る前に、ビューに使われるすべてのデータが"
"フェッチされて、 DTO に復元されるような組み立てフェーズを暗黙的に定義しま"
"す。 Hibernate では1つ目の目的が不要になります。しかしビューのレンダリング処"
"理の間、永続コンテキスト（セッション）をオープンにしたままにしなければ、組み"
"立てフェーズはまだ必要です（分離オブジェクトの中のどのデータが利用可能かにつ"
"いて、プレゼンテーション層と厳密な取り決めをしているビジネスメソッドを考えて"
"みてください）。これは Hibernate 側の問題ではありません。トランザクション内で"
"安全にデータアクセスするための基本的な要件です。"

#. Tag: term
#, no-c-format
msgid "Consider abstracting your business logic from Hibernate:"
msgstr "Hibernate からビジネスロジックを抽象化することを考えましょう。"

#. Tag: para
#, 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
#, no-c-format
msgid "Do not use exotic association mappings:"
msgstr "珍しい関連マッピングは使わないようにしましょう。"

#. Tag: para
#, 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 ""
"よいユースケースに本当の多対多関連があることは稀です。ほとんどの場合「リンク"
"テーブル」の付加的な情報が必要になります。この場合、リンククラスに2つの一対多"
"関連を使う方がずっとよいです。実際ほとんどの場合、関連は一対多と多対一なの"
"で、他のスタイルの関連を使うときは本当に必要かどうかを考えてみてください。"

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