Microsoft Accessで作ったシステムはSmart UIアンチパターンになりやすい

私はいままでMicrosoft Accessでシステムを開発したことがあった。っていうか今も作っている。Accessはシステムが小規模なうちはすごく作りやすい。しかし大きくなるにつれてメンテナンスや拡張がしにくくなる。なぜだろう、とずっと思っていた。

最近「Smart UI アンチパターン」というのを知った。

ビジネスロジックやデータアクセスのコードが、UIのコードと一緒になってしまっている、いわばスパゲッティな状態。
[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場

そして、Accessで作ったシステムはほとんどSmart UIアンチパターンの罠にはまってしまうことに気がついた。

Accessはフォームやコントロールをレコードセット（.NETでいうDataSet）に結びつけることができる。連結フォームと呼ばれるやつだ。これは大変便利な機能だ。というか、連結フォームを使わないならばVB6で作るのと変わりないし、帳票フォームやデータシートなどの複数行のデーターが表示されるフォームはこれ無しでは実現できない。Accessでは連結フォームを使うことは必須とも言える。

問題は、連結フォームで使えるレコードセットが

  1. ソースをSQL文字列（またはテーブル名、クエリー名）で与える
  2. レコードセットはフォームの内部で作成され、外部から与えることができない

という特徴を持っているということだ。

そのため、フォームからDBまで直結されてしまい、ドメインオブジェクトを入れる場所がない。次のような感じになる。

[フォーム（内蔵レコードセット）] → [DB]

たとえドメインロジックを組み込んだレコードセットを作っても、フォームやコントロールに与えて結合することはできない。それでは制御を入れられないのかというと、そんなことはない。

連結フォームでは、フィールドに連結したコントロールの値を変更することでレコードセットのフィールド値を変更することができる。また、コントロールの値が変更されたことをイベントとして捕捉できる。そこで制御をフォームに内蔵されたコード（クラスモジュール）に入れることになる。すると、必然的にドメインロジックはフォームに組み込まれることになる。

[フォーム（ドメインロジック）→（フォーム上のコントロール）→（内蔵レコードセット）] → [DB]

UIがドメインロジックやデータアクセスまで備えている。これはSmart UIに他ならない。

つまり、Accessで普通に作るとSmart UIが出来てしまうのだ。

AccessではSmart UIは避けられないと思う。システムを作る場合には、Smart UIをベースにして、どのようにすればメンテナンス性の高いシステムになるかを考える必要があるのかも知れない。

ちなみに以前に携わったAccessのシステムでは、DBにSQL Serverを使い、トリガとストアドプロシージャでドメインロジックを構成していた。これだと

という役割分担ができて、非常に見通しのよいシステム構成になる。これもひとつの方法だと思う（しかし、データストアを他のDB製品に変更できないという欠点がある）