フレームワークによる開発

1. フレームワークによる開発 for NET FrameWork . Lv３くまーbyやじゅ

2. はじめに 実はどのように開発するのが良いのかよく分からない これは、外部の開発者と接する機会が少ないことと、 Google先生でも教えてくれない為、独自の開発方法 となり、いわば井の中の蛙状態となってしまっている。 ともかく今の開発方法を公開した上で、みなさんの 知識の情報を収集しようという作戦です。

3. 自己紹介 やじゅ＠静岡の田舎　http://blogs.wankuma.com/yaju/ ＳＬ(大井川鉄道)が通っているところに 住んでいます。 セッション ・「ドラえもんの世界をオブジェクト指向で」 　　２月２３日　わんくま同盟東京勉強会＃１７ ・「設計時の見落とし 　Google先生も教えてはくれない」 　　３月２９日　わんくま同盟大阪勉強会＃１７

4. 説明手順 １．開発仕様について ２．フレームワークについて

5. 開発仕様 ・開発内容　（仮定）わんくま販売管理システム ・モジュール構成について ・フォルダ構成について ・アセンブリの配置について ・アプリケーション・ドメインについて ・初回起動が遅いについて ・開発方法について・プロジェクト分割指針ってどうしてます？意見求む・バージョンの付け方ってどうしてます？

6. 開発内容 （仮定）わんくま販売管理システム ・開発規模 　　プログラム本数　１００本 　　ＤＢ Oracle10g 　 ８０テーブル 　・開発ツール 　 　Microsoft Visual Studio 2005 VB.NET2005 　サードパーティ製 　　　入力コンポーネント、グリッドコンポーネント、 　　　帳票作成コンポーネント

7. モジュール構成 メニュー画面(ログイン入力画面を含む)のみ ＥＸＥ形式、それ以外はＤＬＬ形式とする。 １画面(機能)で１プロジェクトとはせずに サブシステム単位でプロジェクトを分割する。 ※ここで言うプロジェクトは、ソリューションファイルを指す。 ※プロジェクト分割方針については、後述 ※タスクスケジューラで動作させる処理は、EXE形式　または　BATファイル＋SQLPlus(ストアド実行) とする。 　単独で動作させたい処理は、別途EXE形式で作成し、その中で該当するDLLを 　呼ぶ形式で作成する。

8. フォルダ構成 ＡＰＰフォルダの中身 wnkMenu.exe 　wnkMenu.exe.config 　wnkMitusmori.dll 　wnkJuchu.dll 　wnkUriage.dll 　wnkSeikyu.dll wnkShire.dll wnkZaiko.dll wnkMaster.dll wnkCommon.dll clsCommon.dll clsControlLibrary.dll clsDBAccess.dll 各サードパーティ製.dll　ｘ　ｎ本 常に最新版がある フォルダを統一 しておき、参照も ＡＰＰから設定する ビルド出力パスも ＡＰＰとする。

9. アセンブリの配置 ．ＮＥＴでは side-by-side が基本なので、ＥＸＥと同じフォルダに ＤＬＬを配置すればいい。 ※ｓｉｄｅ－ｂｙ－ｓｉｄｅは 複数のバージョンを同じコンピュータで実行する機能です。 ＧＡＣ（グローバル アセンブリ キャッシュ）への登録は、開発中は お勧めしません。開発の終わり頃に登録するくらいでもいいも・・・ アセンブリの検索順 既に読込み済のもの→ＧＡＣ→コードベース→プローブ(探査) ．ＮＥＴ ＦｒａｍｅＷｏｒｋのウリの１つのキャッチフレーズとして 「コピーしただけでインストール完了」があるらしい。

10. アプリケーション・ドメイン ．ＮＥＴアプリケーションでは１プロセスの 中に型やセキュリティを管理する単位として、 ＡｐｐＤｏｍａｉｎという器を作成する。 ＥＸＥ形式では、１プロセスとなるため、 ＡｐｐＤｏｍａｉｎを作成することになり 起動コストが高くなる。 ＤＬＬ形式では、ＡｐｐＤｏｍａｉｎ内に ＤＬＬファイルが読み込まれ実行する。 注意点 　ＤＬＬのアンロードはＡｐｐＤｏｍａｉｎ 　単位となるため、違う種類のＤＬＬを読み 　込めば、それだけメモリが増大する。

11. 初回起動が遅い ＰＣ起動直後は、ＣＬＲ（共通言語ランタイム）やＪＩＴコンパイラなど 必要なモジュールが読み込み実行され、かつアプリケーションドメインの 初期化に時間をとられるため、遅い。 なお、ＶＩＳＴＡ上で．ＮＥＴアプリの起動が速いのは、上記処理が既に 終わっているためです。 ◆対応策： 　・システムのスタートアップ時に画面が表示されない小さな．ＮＥＴアプリを起動して 　　ＣＬＲなどをロードさせてしまう。 　・アンマネージなスプラッシュ・スクリーンを作成して体感速度をごまかす。 　・ＮＧＥＮでネイティブなコードにコンパイル、でもネイティブのまま配布はできない 　・Ｓｃｏｔｔさんのｂｌｏｇによると、起動時間（コールドスタートアップ）の改善が 　　２００８年の夏くらいに行う予定のようで、２５－４０％の改善予想とのこと。

12. 開発方法 ・開発用にｄｌｌを起動するドライバを作成 外部プログラムの設定に指定 　コマンドラインに起動内容を設定 （パラメータは、キー：値でセット、例 JUCHU_NO:1234SortedList型で格納）

13. プロジェクト分割指針 アセンブリ（ソリューション）をどう作成するべきか？ システム内に１００の機能(画面)があったとします。 その中は８つ(見積、受注、売上、請求、発注、仕入、在庫、マスタ保守)の サブシステムが分かれており、メニュー画面が１つあります。 ※パターンが多くなるので、システム共通系としてＤＬＬが数個あることにします。 １．全ての機能(画面)を１つのＥＸＥとする。 ２．メニューはＥＸＥ、機能(画面)ごとにＥＸＥとする ３．メニューはＥＸＥ、関連機能（サブシステム）ごとにＥＸＥとする。 ４．メニューはＥＸＥ、機能(画面)ごとにＤＬＬとする ５．メニューはＥＸＥ、関連機能（サブシステム）ごとにＤＬＬとする。 ６．その他 ※機能(画面)ごとＥＸＥまたはＤＬＬにするとファイル管理コストばかり跳ね 　上がってしまう予感がします。 保守性とのトレードオフですかね。

14. バージョンの付け方 ＜メジャー・バージョン＞.＜マイナー・バージョン＞.＜ビルド番号＞.＜リビジョン＞ 開発時のアセンブリバージョン、ファイルバージョン　基本は同じ値とする？ 各項目値は、0～65534 アセンブリバージョン　 1.0.1234.1 アセンブリバージョン　 1.0.1.1234 アセンブリバージョン　 1.0.2008.712 アセンブリバージョン　 1.2008.7.12 アセンブリバージョン　2008.7.12.1管理上、日付を入れたかったりする

15. フレームワーク ・開発目的について ・共通仕様を決める ・フォーム、入力コントロールの継承と拡張 について ・抽象化を理解について ・ポリモーフィズムについて ・インターフェイスについて ・簡易フロー ・前処理・本処理・後処理について ・入力チェックの統一化について ・ソースサンプル ・まとめ

16. 開発目的 ・共通機能を内包することによりアプリケーション側の コードの絶対量が削減され、製造者の負担を減らす。 コードの統一化により、開発者のスキルの差が少なく なり、品質をある程度均一されることにより信頼性が 向上する。 ・型にはめる方が楽 自由すぎると思わぬ不具合を引き起こす可能性が高い 　型にはめてしまう事で、中身の製造に専念させる。

17. 共通仕様を決める ・画面最上部にファンクションキーボタン表示 ・Ｅｎｔｅｒキーで項目移動 ・○○時(登録など)、再度、項目移動のチェック + 全体の整合性チェック ・項目移動で内容に変更なしなら、入力チェックはしない。 ・背景黄色の項目は検索画面を呼び出し可能 (Ｆ８キー連動）　 ・背景緑色の項目は表示専用　 ・入力項目を編集したなら、クリア時・終了時に確認メッセージを出力 ・検索項目ならＦ８キーを有効化、それ以外は無効化 ・グリッドコントロールならＦ５～Ｆ７キーを有効化、それ以外は無効化 ・行挿入、行追加が最大行数に到達ならＦ５、Ｆ６キー無効化 ・行削除が最低行数ならＦ７キーを無効化 などなど

18. フォーム、入力コントロール の継承と拡張 ・ファンクションキーを配置、モード表示ラベル、 　タイトル表示ラベル、ステータスバー ・フォームの拡張プロパティ 　編集フラグ、処理モード、フォームタイプ 　ファンクションキー表示、検索画面の結果受取 　検索保持コントロール、グリッド保持コント ロール　などなど ・入力コントロールの拡張プロパティ 　拡張Ｅｎａｂｌｅｄ、検索呼出 　値変更通知、全チェック、項目値保持 　などなど

19. インターフェイス インターフェイスというのは外部に公開するサービス(メソッド やプロパティ等)の定義のセットです。 今回でいえば、拡張したサービスを最小単位のクラス？として 他クラスからアクセス可能とさせたいときに使っています。 インターフェイス　IFWForm、IFWControl、IFWGridView など

20. グー へび チョキ かえる パー ナメクジ 抽象化を理解 関係・機能を抽出し、システム化したもの 虫拳 ジャンケン ３すくみ 関係を抽象化

21. 呼び出す側Ａ 呼び出す側Ｂ 呼び出す側 呼び出す側Ｃ 呼び出される側Ｘ 呼び出される側Ｙ 呼び出される側Ｚ 呼び出される側 ポリモーフィズム 共通サブルーチン 呼び出す側が増えても 呼び出される側を修正 する必要がない　 ポリモーフィズム 呼び出される側が増え ても、呼び出す側を 修正する必要がない　 オーバーライド(再定義)によって、中身を書き換える。

22. ファンクションキー 画面起動 検索画面呼出 モード変更 F1- F4 クリアアクション 更新アクション ＣＳＶアクション 印刷アクション 処理振分け 初期化処理 検索呼出処理 全入力チェック 全入力チェック 全入力チェック Ｌｏａｄ 前処理 各アクション 前処理 前処理 前処理 前処理 本処理 後処理 本処理 本処理 本処理 本処理 初期化処理 後処理 後処理 後処理 後処理 初期化処理 初期化処理 初期化処理 初期化処理 簡易フロー図 初期化処理

23. アクション 前処理 本処理 後処理 前処理・本処理・後処理 例 基本の考え方 更新アクション 各処理で異常なら次の処理へは 進まないで、処理を抜ける。 全入力チェック 確認メッセージを出力 登録します。よろしいですか？ 前処理 トランザクション開始 本処理 正常ならコミット 異常ならロールバック 完了メッセージを出力 登録が完了しました。 後処理 継承元フォームにある程度記述し 必要なら、継承先にて書き換える。 初期化処理

24. Ｅｎｔｅｒキー/Ｔａｂ 移動で編集あり 検索画面の戻りの タイミング 全入力チェック (更新ボタン前など) 各入力コントロールの 入力チェックＩｎｐｕｔＣｈｅｃｋ 入力チェックの統一化 ・各入力コントロールの入力チェック処理を、統一の入力チェックメソッド ＩｎｐｕｔＣｈｅｃｋ　に統一する。 　人によって、チェック処理を書くイベント(Leave ,Validating, Validated, Enter)が違っていた　 テキスト型、マスク型、数値専用型、日付型、コンボボックス型のＶａｌｉｄａｔｉｎｇ チェックボックス型、ラジオボタン型のＣｈｅｃｋＣｈａｎｇｅｄ どこから呼ばれたのかは 引数で渡されてくる。 継承先フォームにて 入力チェック処理を記述

25. ソースサンプル '------------------------------------------------------------------ '更新前処理 '------------------------------------------------------------------ Protected Overrides Function UpdateBefore() As Boolean '入力チェック以外の関連チェック処理 For Row = 0 To Detail.Rows.Count - 1 If IsItemCheck(Row,Shohin_cd) = False Then Return False End If Next '親メソッド呼出 更新確認メッセージ出力 If MyBase.UpdateBefore() = False Then Return False End If Return True End Function

26. まとめ クラス作りは思いやりが大切 複数のプログラマが１つのシステムを構築する場合には 「私はクラスを作る人、貴方はクラスを使う人」という 役割分担ができます。 クラスを作る人は、クラスを使う人に楽をさせるための 工夫をしましょう。 それが、オブジェクト指向プログラミングを効果的に 実践するための秘訣です。 「思いやり」が大事なのです。

27. おしまい ご清聴ありがとうございました。