論理削除、共通カラム(作成日時、ユーザーなど)対応

DaoインターフェースのDeleteメソッドは使用せずに、LogicalDeleteメソッドを定義して、SQLアトリビュートでupdate文を書いいてあげることで論理削除に対応。
あとEntityクラスの更新日、作成日に少し仕掛けを入れて更新する時点の時刻を取得するようにした。更新日時は毎回DateTime.Nowを返して、作成日時は読み込んだ値がNullだった場合にはDateTime.Now、そうでなければ読み込んだ値を返すように設定。
普通のDateTimeではNullが入らないので、Nullableにして対応。
また、サロゲートキーのカラムもNullableにしてIDアトリビュートで自動採番。
ちょっとIDType.IDENTITYがうまくいかなかったのでシーケンスにて対応した。(DBはPostgresql8.3)


あとEntity、Daoの生成ツールを作ってしまえば
コーディング標準読み合わせ
・ソリューションのプロジェクト構成決め
をやってやっと開発着手(タスク洗い出し)だ!
初回イテレーション用のバーンダウンもつくった!(Excelで・・・うーん)
あ、壁はり用のカードつくってない。


ただ、サービス側のクラスをクライアント側で使用すると単なるデータオブジェクトになってしまうのが残念。このままではドメインオブジェクト(的なクラス群)をクライアント側で使えない。たとえばあるクラスのリストを操作したい場合は、画面側、サービス側ともにあるんだけど、その際にサービス側で作成したファーストクラスコレクションのようなクラスを画面側では使えない。。。
共通で使うクラス群はクライアント側プロジェクトからも直接プロジェクト参照させたほうがいいのかな。でもデータアクセスは出来ないから、永続化の仕組みとは別のところだけをプロジェクトでくくらないといけない。んー。Util+Entiry、Dao、WebService、Clientといったプロジェクト構成がいいのかな。


しかしChuck Norrisすげ〜

Chuck Norris can compile syntax errors.