WPF MVVM L@bo #4 ~ DB が見えるのは嫌なので 3 階層 に AbstractFactory したいと思います。 ~

← 前回記事【WPF MVVM L@bo #3 ~ SQLite ですが? ~】

前回はプロトタイプアプリで使用する DB としてファイルベース DB の SQLite とその周辺ツール類を紹介したので、今回は DB にアクセスするための 3 階層アーキテクチャと使用する DB をアプリケーション層から隠蔽するための AbstractFactory パターンを紹介します。

尚、この記事は Visual Studio 2019 Community Edition で .NET Core 3.1 以上 と C# + Prism 7.2 以降 + ReactiveProperty + Livet + MahApps.Metro + Material Design In XAML Toolkit + SQLite を使用して 、WPF アプリケーションを MVVM パターンで作成するのが目的で、C# での基本的なコーディング知識を持っている人が対象です。

DB への I/O

WPF Prism episode シリーズからこの新シリーズまでを通して画面動作関連のサンプル紹介が主な内容で、データの I/O 等の内部処理についてはほとんど取り上げてきませんでしたが、今回の新連載ではどんどん扱っていこうと思っています。

WPF から DBへの I/O と言っても特別なことが必要な訳ではなく Windows Form や Web の場合と変わりません。
.NET から DB へアクセスするには System.Data 名前空間に用意されている ADO.NET を使用すれば特に困ることは無いと思いますが、ADO.NET 標準の方法だと SQL 文を発行する度に『DB へ接続 → Command を生成 → 実行』のような処理を何度も繰り返し書く必要があり面倒なので、DB アクセスライブラリを作成してコード量を減らしたり、抽象化していることも多いと思います。

管理人も今回プロトタイプアプリを作るついでに DB へのアクセスが多少楽になる(はずの)汎用の DB アクセスライブラリを作成したので、その内容を紹介します。

尚、ADO.NET の標準的な使用法は検索すればいくらでも見つかるはずなのでそちらを見てもらうとして、次章以降は ADO.NET から SQL を発行するような基本知識は持っている前提の内容です。

多階層アーキテクチャ

今回管理人が作成した DB へのアクセスライブラリは fig. 1 のような 3 階層アーキテクチャのデータ層に位置するクラス群として設計しました。
今時なので、多階層アーキテクチャで設計されていないアプリなんて無いんじゃないの?と思えるくらい当たり前のアーキテクチャだと思っていますが、業務系の開発現場ではちゃんと多階層で設計されたライブラリに出会うことは稀(管理人個人の感想です)なので一応紹介することにします。

fig.1 3 階層アーキテクチャ

fig. 1 は多階層アーキテクチャの中で最も基本と言える 3 階層アーキテクチャ(三層構造)で、他の 5 階層や 7 階層等はこの 3 階層からの派生です。
3 階層の各レイヤーは以下のような役割を持っています。

▼ プレゼンテーション層
UI 層とも呼ばれ、ユーザーへの情報表示や、ユーザーからの入力を受け付ける機能を担当するレイヤーで、Windows Form では Form、WPF では Window、UserControl 等の UI 部品、Web ではブラウザに描画される View がこのレイヤーに位置します。
▼ アプリケーション層
ビジネスロジック層、ファンクション層等とも呼ばれるレイヤーで、下で紹介するデータ層とプレゼンテーション層を仲介する役割を持ちます。
5 階層、7 階層等のアーキテクチャはこの層を『責務』、『関心』、『再利用性』に注目して分割したアーキテクチャです。
▼ データ層
パーシステンス層とも呼ばれるデータ永続化層。業務系開発の大部分はこのレイヤーに RDBMS が位置し、データの読込・保存機能を担うレイヤーです。

多階層アーキテクチャについてはかなり古い記事ですが【階層アーキテクチャの利点は、複雑さの減少 – ITmedia エンタープライズ】が詳しく、主に 5、7 階層アーキテクチャについて紹介されています。
(全て読むには無料の会員登録が必要かもしれません)

MVVM と 多層アーキテクチャ

3 階層アーキテクチャの各レイヤーは MVVM の各要素の役割と被る所も多く、2 つの概念図を対比すると fig. 2 のようになります。

fig.2 3 階層アーキテクチャと MVVM

WPF Prism episode シリーズでも何度か書いた『Model は通常、何層かに分ける』とは fig. 2 のように Model は最低でも 2 階層には分けるべきと考えているからです。
加えて、MVVM は UI 層に特化したパターンであり、View、ViewModel 以外は全て Model に分類されると言う意味も fig. 2 から分かってもらえると思います。

fig. 1 のようなアーキテクチャと MVVM のようなデザインパターンは混同されがちですが、振る舞い等を定義するデザインパターンと違って、多階層アーキテクチャは【責務】、【関心】、【再利用性】に注目してクラスをグループ化し、モジュールを配置するレイヤーの位置とデータの受け渡し順を明確にするための指標のようなもの考えておけば良いと思います。

そのため、デザインパターンのように役割が厳密に定義されているわけではありませんが、多階層アーキテクチャはデータの流れやクラスの関心、システム全体の構造等をチーム内で共通に認識するような用途に適していると思います。

多階層アーキテクチャとデザインパターンでは適用分野が異なるので、多階層アーキテクチャと MVVM のどちらを採用するという話ではなく、『システム全体としては 3 層で、プレゼンテーション層は MVVM にする』が正しい表現です。
この辺りの話は『MVC、3 層アーキテクチャから設計を学び始めるための基礎知識 – Qiita』等で詳しく解説されています。(リンク先の内容は MVVM ではなく MVC ですが基本的な考え方は変わりません)

3 階層アーキテクチャの例には Web がよく引き合いに出される(出し易い)事が多いですが、Web だから 3 階層にする、デスクトップアプリだから 2 階層で良いと言うものではなくいくつかの例外を除いてどんなアプリケーションでも最低 3 階層アーキテクチャで作成すべきだと管理人は考えていて、特に データの I/O を機能として持つアプリであれば 3 階層アーキテクチャは必須だと思っています。
次章からはコードを交えながら実装内容を紹介していきます。

DataAccess ライブラリ

作成中のプロトタイプアプリは全体を fig. 3 のような 3 階層アーキテクチャで設計しています。

fig.3 3階層 MVVM

fig. 3 のような構成にすることで VM からデータ層を直接呼び出すことができなくなり、必ずアプリケーション層を通してデータ層へアクセスすることを強制できます

ですが、単純に fig. 3 のまま作成してしまうとデータ層が SQLite に依存してしまうため、バックエンド DB を変更したいような場合等の影響が大きいことが予想できますし、作成した DataAcces ライブラリを他プロジェクトに再利用したい場合でも SQLite しか使用できないのはライブラリとしてはお粗末なので、データ層から DBMS への依存を取り除くことにします。

尚、今回のエントリではプレゼンテーション層やアプリケーション層はとりあえず置いておいて、データ層についてのみ紹介します。

データ層から DBMS への依存を取り除く

DBMS への依存をデータ層から取り除くための AbstractFactory(fig. 4 パープルの IDbAccessHelper)を fig. 20 のように配置して HalationGhostDbAccessBase 内部で使用する設計にしました。

fig.4 DataAccessベースクラス図

fig. 4 のクラス群は他プロジェクトへも使い回せるようにプロトタイプアプリとは別プロジェクトに分割して作成しています。



DataAccess クラスのベースクラス

アプリケーション層と実際にやり取りする DataAccess クラスは src. 3 の HalationGhostDbAccessBase を継承する前提で設計しています。

HalationGhostDbAccessBase は DB との Connection を保持することが主な役割のクラスなので、IDisposable を継承してクラスの生存期間と DbConnection の生存期間は一致する設計にしています。
そのため、接続設定は HalationGhostDbAccessBase のコンストラクタでシリアライズしたファイルを読み込むようにしています。

一般的に DB の接続文字列は App.config や Web.config に保存した値を使用することが多いと思いますが、ここで紹介したように階層を分けているとスタートアッププロジェクトで取得した接続文字列を順に渡していく必要があり又、再利用する場合の考慮も面倒なのでライブラリ自身で読み込むようにしました。

そのため、ライブラリを使用するアプリが接続設定ファイルの場所を変更したい場合はこの DbConnectionSettingLoader のみ変更すれば対応できるようにしています。
DbConnectionSettingLoader も別プロジェクトに分けた方が更に変更の影響を受けにくくなると思いますが、今回はプロトタイプなのでとりあえず同一プロジェクトに置いています)

又、virtual で定義した HalationGhostDbAccessBase.getConnectionNumber メソッドを継承先でオーバーライドすることで接続先 DB を変更できるようにしているので、例えば Oracle と SQLite の両方に接続する必要があるシステムでも継承先の DataAccess クラスから接続先 DB を切り替えることができます。

AbstractFactory パターン

そして AbstractFactory として動作する IDbAccessHelper(名前がパターン名と一致していません…)は src. 4 のように定義しました。

ADO.NET には元々 AbstractFactory の使用を想定(?)した DB 操作関連のクラスが System.Data.Common に含まれているので、src. 4 ではその中から DbConnection と DbTransaction のみ公開しています。
DB 操作関連のクラスは他にも DbCommand や DbDataReader 等がありますが、公開していない理由は次回エントリで紹介する予定です。

又、src. 4 でインタフェースのメソッドに【public】が付いているのは Visual Studio 2019(Ver.16.3)以降で対応した『インターフェイスのデフォルト実装』と言う C# 8.0 の新機能のおかげです。ここではメソッドにアクセシビリティを付けただけで特に新機能には関係ありませんが、興味があれば岩永さん主宰の『インターフェイスのデフォルト実装 – ++C++; // 未確認飛行 C』等を見ると良いと思います。

そして src. 4 の IDbAccessHelper を継承した src. 5 の SqliteAccessHelper は SQLite 固有の処理なので別プロジェクトに分けて作成しています。

src. 5 のように各 DB 固有クラス(SQLiteConnection、SQLiteTransaction 等)の生成や固有設定等を DB 固有のクラスに閉じ込めることで Oracle への接続が必要になれば OracleAccessHelper、Microsoft Access への接続が必要になれば MsAccessAccessHelper を作成 & 追加するだけで対応できるようになります。

このような構成にしておけば DBMS を変更する必要が出てきた場合でも、実際に SQL を記述した DataAccess はほとんど変更の必要は無く DBMS を変更できます
RDBMS 固有の SQL が書かれている場合は、アプリの DataAccess も変更が必要になります)



補足として接続する DBMS が追加・変更になった場合は、IDbAccessHelper を継承したクラスの追加に加えて src. 6 の DbAccessHelperFactory も変更する必要があります。

まあ、変更が必要と言っても src. 6 のハイライト部分のみ追記するだけで済むので影響範囲は限定できると思います。

この連載で作成しているプロトタイプアプリから DB に接続するだけで考えるとかなり大袈裟な構成になってしまいましたが、ここで作成しておけば別のアプリにも流用できるので多少労力がかかったとしても無駄にはならないはずと考えています。

これでアプリから DB へ接続する準備は整ったので、実際のプロトタイプアプリからデータを読み書きする方法を紹介したいと思いますが、長くなりそうなので次回のエントリに続きます。

今回のソースコードもいつもの通り GitHub リポジトリ に上げています。

 

【WPF MVVM L@bo #5 ~ ようこそ Dapper 至上主義の DataAccess へ ~】次回記事 →

 

 

おすすめ

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

%d人のブロガーが「いいね」をつけました。