デザインパターンを使ってみる。

先日読み終えたデザインパターンの復習を兼ねてサンプルアプリを作ってみました。

作成にあたって

1．デザインパターンを使ってみる。
2．単体テスト用のINSERT文を発行するようなアプリを作る。
3．単体テストもせっかくだからおさらいしてみる。

ということを考えて作ってみました。



DACの単体テストなどを行う時に発行するINSERT文。
先にDBもしくはExcelなどでデータパターンを作っておいてそれをINSERT文またはCSV（未実装）にします。

画面を見てわかると思いますが、現在Oracleは未実装。
理由はOracleをインストールしたくなかったから。どうやらOracleもExpress Editionなるものが出ていて試すことができそうでしたが、Virtual PCにインストールしてループバック環境作ってODP.NET入れて…と考えているうちに後回しに。

でもいいんです。Oracleのロジックは追加できるように作ったから♪

ただ、途中まで作ってみたのですがやはりデザインパターンを上手く使えていない気がする。。。
このブログのページビューが少ない甘えと、記事を追加して早くトップページから見えないようにする決意をもとにだめなコードダイアグラムを載せてみます。




あぁ、汚くてすみません。ダメ出しがあればコメント頂けるとうれしいです。

問題点として認識していること。
1．クラスの命名がひどい。
2．BCにConnectionStringを持っている。他、DA周りがBCに入っている。
3．BCFactoryはAbstractFactoryのつもりですが、そもそもここで使う必要がない。（Factoryを使えばいいのかなぁなんて思っています。）

うぅぅ。人が作ってるのを見るのと自分で考えるとでは違いますね。。。
死ねばいいのに。

ここで考えたのはデータベースの種類によってクラスを分けることと出力方法によってクラスを分けることでした。なのでOracle処理用のクラスを追加すればOracleの処理が追加できるし、CSV処理用のクラスを追加すればCSV出力処理も追加できるようになります。

DA周りがBCに入ってしまったのはADO.NET2.0で追加されたSystem.Data.Common名前空間のクラスを使っているうちに"あっ"という間にこんなんなってました。


思ったこと。
1．デザインパターンを理解すればきっとコーディングのスピードも上がるだろう。
　>空間で把握できるようになるからそうかなと。だからもっと勉強する。いや、もっと実装する。
2．赤間本Vol.4と"アプリケーションアーキテクチャ"を読もう。
　>デザインパターンだけだと局所的な視点でしか理解できないと思ったため。幸い2つともあるし。
3．WebテストのDataSourceを紐づけるXMLが出力対象にできたらWebテスト楽かもなぁ。
　>過去、DataSourceの紐づけがすごく面倒だったため。