SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

現役エンジニア直伝! 「現場」で使えるコンポーネント活用術(SPREAD)(AD)

実践WPF業務アプリケーションのアーキテクチャ【概要編】 ~ マイクロソフト公式サンプルデータベースAdventureWorksを題材に

  • X ポスト
  • このエントリーをはてなブックマークに追加

WPFアプリケーション層 詳細

 さてWPFアプリケーション層のレイヤー分割についてですが、パターンAにするかパターンBにするか悩ましいところです。

WPFアプリケーション内部レイヤー
WPFアプリケーション内部レイヤー

 まず、プレゼンテーションとドメインを分離(Presentation Domain SeparationつまりPDSを実現)するために、MVVMモデルを採用します。WPFは強力なバインディング機構をもちます。そのWPFアプリケーションでPDSを実現するために考えられたのが、MVVMモデルです。このためWPFとMVVMは非常に相性が良いパターンです。WPFでアプリケーションを構築するにあたり、あえて他のパターンを採用する理由もないため、MVVMモデルを採用することとしました。

 ここまでは問題ありません。問題はModel層です。

 私は通常は左のパターンAを採用するケースが多いです。これは一つのユースケースの実現に、二つ以上の画面が登場することを普段は想定しているからです。

 一つのユースケースが複数の画面にまたがる場合、ユースケースの状態(情報)を管理するにはどうすれば良いか?という問題とユースケース内でロジックを共有化するのに、Usecaseレイヤーがあった方が都合が良いことが多いからです。

 しかし本システムでは一つのユースケースが複数の画面によって構成されることは現時点では想定されていません。またユースケース固有の複雑なロジックも存在しません。非常にシンプルなマスター管理のCRUDが発生するのみで、それらは基本的にWCFによるサーバーサイドの実装に含まれます。

 そこで本システムではパターンBを採用することとしました。

 なおService Client層は、WCFサービスとの通信レイヤーです。実際にはWCFのシグニチャを定義したinterfaceを用いて、ChannelFactoryから自動生成するため実装は必要ありません。この点がWCFの開発生産性が高い所以です。

WCFサービス層 詳細

 WCFサービスは、次のレイヤー構成にて実現します。

WCFサービス内部レイヤー
WCFサービス内部レイヤー

 Service Host層は、WCFサービスの実装をホスティングする層になります。WCFをホスティングする仕組みには、二つの代表的な仕組みがあります。

  1. Windows Service上でのセルフホスティング
  2. IIS上でのホスティング

 これらは機能的には大きな差異はありません。運用する環境において、Windows ServiceとIISのいずれでホスティングした方が、運用が容易になるかという側面で検討すると良いと思います。

 今回のサンプルの実装においては、Windows 10上だとIISでホスティングする実装は難しいため、Windows Serviceとして実装しています。これはWindows 10上のLocal IISでは統合Windows認証が利用できず、IIS ExpressではHTTP・HTTPS以外のプロトコルが利用できず、IISのホスティングを利用する場合は別途Windows Serverが必要になってしまうことから、サンプル実装としては向かないという判断によるものです。

 続いて、Service Implementation層です。これはWCFとして公開されるサービスの実装レイヤーになります。トランザクション管理を含むビジネスロジックが実装されます。実際のSQLの発行はDatabase Access層に移譲します。

 ところでWeb上のWCFのサンプル実装を見ると、Service Host層とService Implementation層が一つに統合されている例が多く見られます。しかしその手法を取った場合、Windowsサービスでホストしていると劇的に開発生産性が落ちます。

 開発時はWindowsサービスに登録するモジュールは、ビルド先のbinフォルダに配置されたものを登録したいと考えるでしょう。しかしそうした場合、Windowsサービスを止めないとビルドがエラーとなります。Windowsサービスが実行モジュールのファイルハンドルをロックしているためです。かと言って、Windowsサービスに登録するモジュールを別フォルダに置いたとしても、実行する際には毎回サービスを止めてファイルをコピーする必要があります。またWindowsサービスをデバッグするには、プロセスにアタッチする必要があります。F5を押して終わりという訳にはいきません。

 また単純に、ユニットテストの対象コードと非対象コードが混在してしまうため、テストの終了判断が難しくなるという問題もあります。

 これらの理由から、まずService Host層とService Implemantation層を分離します。その上で運用時はWindows Serviceに、実装時はWindowsコンソールアプリケーションにService Implemantation層をホストすることで全ての課題は解決することができます。

 詳細はGitHubをご覧ください。

 最後に、Database Asscess層ではデータベースへのSQLの発行と、結果のオブジェクトへの変換を実装します。トランザクション管理はService Implementation層で行うため、Service Implementation層で作成されたConnectionオブジェクトを利用して、データベース処理を実装します。

次のページ
コンポーネントモデル

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
現役エンジニア直伝! 「現場」で使えるコンポーネント活用術(SPREAD)連載記事一覧

もっと読む

この記事の著者

中村 充志(リコージャパン株式会社)(ナカムラ アツシ)

 Microsoft MVP for Visual Studio and Development Technologies リコージャパン株式会社 金融事業部 金融ソリューション開発部所属。 エンタープライズ領域での業務システム開発におけるアプリケーション アーキテクト・プログラマおよび中間管理職。 業務ではWPFおよびASP.NETを用いた業務システム開発が中心。 SI案件において、テスト・保守容易性を担保した、アーキテクチャ構築を得意としている。 GitHub:https://github.com/nuitsjp Twitter:@nuits_jp 著書 『Essential Xamarin ネイティブからクロスプラットフォームまで モバイル.NETの世界』(共著) 『Extensive Xamarin ─ひろがるXamarinの世界─』(共著)

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/10727 2018/04/10 16:28

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング