読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

O/Rマッピングツールに対する誤解をときたい -実装編 Part2-

NHibernate OOP

Part1を読む

プログラム設計

クラス設計

このプログラムの核となるクラス(ドメインモデル)を以下に示します。


f:id:JunichiIto:20101223052810p:image:w600


この図はER図でもなく、テーブル設計図ではありません。
あくまでクラス図です。
基本的にこれがこのままC#のコードとして実装されます。
しかし、データベースのテーブルとしてはこのまま実装することはできません。
Part1でもお話しした通り、テーブルの説明は一番最後に行います。


注目してほしいのは書籍クラスと和書クラス、洋書クラスの関係です。
書籍クラスは抽象クラスとなっています。
発送予定日の計算ルールが和書と洋書によって異なるため、「発送予定日を計算する」メソッドを抽象メソッドとし、具体的な実装は和書クラスと洋書クラス内でそれぞれ行われます。

レイヤー構成

このプログラムでは以下のような論理三階層アーキテクチャを採用します。


f:id:JunichiIto:20101223053019p:image:w600


三階層といっても一番下の階層はNHibernateが担当しているので、実際にこちらで実装するのは上の2階層だけです。
DAO(Data Access Object)パターンなどを使って、FacadeをNHibernateに依存させないような設計も考えられますが、あまりコードが分散するのとサンプルコードが説明しづらくなるのでこのようなレイヤー構成にしました。

処理シーケンス

「書籍注文ページ」の「注文する」ボタンを押したあとの処理シーケンスを以下に示します。


f:id:JunichiIto:20101223053022p:image:w600


注目してほしいのは「書籍を探す」から「発送予定日を返す」までのシーケンスです。
NHibernateは漠然と書籍クラスを返しますが、実際には和書クラスか洋書クラスのいずれかです。
ただし注文Facadeはそれがどちらのクラスなのかを意識しません。
注文Facadeは単純に書籍に対して「発送を予約する」とメッセージを送れば、適切な発送予定日が返却されます。
仕様上では「和書の場合」「洋書の場合」という条件分岐が発生していますが、ソースコード上ではこの条件分岐は登場しません。


オブジェクト指向に詳しい方ならもうお分かりだと思いますが、これが有名な「ポリモーフィズム」です。
詳しくは実装コードの紹介時に説明したいと思います。


プログラム設計に関する説明は以上です。
次回はみなさんお待ちかねの実装コードを説明していきます。


Part3を読む