実践WPF業務アプリケーションのアーキテクチャ【概要編】 ～ マイクロソフト公式サンプルデータベースAdventureWorksを題材に
-
- Page 3
論理ビュー
システム全体レイヤーモデル
本システムは、次のとおりWPFによるWindowsアプリケーションをユーザーインターフェースとした、3層モデルを採用します。
3層モデルの選定理由
まず、クライアントにWindowsアプリケーションを採用した場合、3層アーキテクチャではなく2層のクライアント・サーバー型アーキテクチャも検討対象に上げられると思います。
ここでは、次の理由によって3層モデルの採用を決定しました。
- クライアント・サーバー型アーキテクチャではセキュリティ的な課題解決が困難
- トランザクション処理の実装は、クライアントの実装言語と統一したい
- データベースはスケールアウトが困難
まずクライアントから直接SQLでテーブル操作可能な形でデータベースを公開した場合、基幹システムであることからセキュリティリスクが問題であると考えました。
クライアントから直接データベースへ接続するためには、そもそもデータベースがネットワークレベルで接続可能な領域に公開されている必要があります。またクライアント・サーバー型アーキテクチャを採用した場合、データベースへの接続情報をクライアントアプリケーション内に含める必要があります。もちろん暗号化することは可能ですが、アプリケーションで復元できる以上、ユーザーが何らかの形で復元して接続情報を得ることを完全に防ぐことはできません。またデータベースの機能で、行レベルのアクセス制御を行うことは困難です。
クライアント・サーバー型で、なおかつセキュリティを担保してデータベースを利用するとします。その場合、SQL Serverであれば認証に統合Windows認証などを用いた上で、データベース操作は全てストアドプロシージャとして作成するといった形で実現は可能です。
しかしこの場合、クライアントの実装言語と、トランザクション処理の実装言語が異なってしまうため、要員のアサインなどが難しくなります。
また仮にSQL CLRを利用するなり、Transact-SQLに長けた人材が獲得できたとした場合でも、トランザクション関連の処理は全てデータベースサーバー上で実行されることになります。データベースはスケールアウトが困難なことから、データベースサーバーには可能な限りデータベースとしての処理以外は載せたくないとも考えました。
また、そもそもサーバーサイドの処理はデータベース操作のみとも限りません。
これらの複合的な要因から、3層モデルを採用することとしました。
WPFアプリケーションの選定理由
大く3点の理由があります。
- 高いユーザ操作性が求められている
- 利用者の端末がWindows 10で統一されている
- 技術的安定性が高く、リプレースまでアーキテクチャの維持が容易と思われる
Webアプリケーションを採用した場合、上記を満たしたうえで、高い開発生産性を発揮することは困難であると考えられるため、WPFアプリケーションに決定しました。
なお一般的にWebアプリケーションと比較してWindowsアプリケーションの場合、配布の側面で不利なケースも考えられます。しかし今回の場合は配布先が社内のWindows 10限定であることから、Click Onceを併用することで配布の利便性でも劣らないものと判断しました。
そもそも、個人的にはClick Onceが利用可能な状況下で、あえて業務システムをWebアプリケーションで作る理由は少ないと思っています。実際には顧客の（主に配布が困難であるという思い込みによる）要求でWebアプリケーションで構築するケースが多いでしょう。しかし今回はWPFを選択しました。
WCFサービスの選定理由
.NETアーキテクチャでトランザクション処理などをサービスとして公開する場合、代表的な選択肢として次の二つが考えられます。
- ASP.NET Web APIによるRESTfulサービス
- WCFによるRPCサービス
現在、一般的にはRESTfulサービスの方が主流です。もちろん、WCFでもRESTfulサービスは公開可能ですが、WCFは元々がSOAPベースのWebサービス構築のために設計されたものであり、ASP.NET Web APIの方が構造がシンプルでパフォーマンスも良好です。
しかし、ここではWCFをnet.tcpプロトコルで利用することとしました。主な理由は次の3点です。
- net.tcpを利用することでトランスポートレベルの暗号化・認証が利用できる
- バイナリフォーマットであるため高速なメッセージ交換が可能
- WCFは開発生産性が非常に高い
Web上に公開する場合、net.tcpの選択は困難ですが、イントラ上のオンプレミスシステムであればプロトコルとして採用に問題はありません。また接続のセキュリティ担保も容易であることから、net.tcpプロトコルによるWCFサービスを採用しました。
逆にインターネット上にサービスを公開するのであれば、現時点であればASP.NET Web APIが適切なケースが多いものと思います。
この記事は参考になりましたか？
- 現役エンジニア直伝！ 「現場」で使えるコンポーネント活用術（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】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか？
この記事をシェア
