A/V重要

Audio/VideoでもAdult/Videoでもない。Authentication/Validationだ。

拙作の.NET WindowsFormsベースのリッチクライアント用フレームワークだが、その機能は大よそ以下の10に分類することができる。

• プレゼンテーションレイヤ
  1. 認証(Authentication)
  2. 検証(Validation)
  3. データバインディング(DTO)
• ビジネスロジックレイヤ
  1. アプリケーション間通信
  2. レイヤ間データ変換(DxO)
  3. サーバ通信(RPC/SOA)
• その他
  1. ロギング
  2. 配布/更新
  3. DIコンテナ
  4. AOP

フレームワークは一種の「半製品」なので、そのまま何もせずに個々のアプリケーションで使われることはあり得ず、よく使われる部分ほど適用するためのカスタマイズ、具体的には追加のプログラミングを必要とする。
これら機能が実際の業務アプリケーションに適用する際にどれだけ手をいれる頻度が高かったかをざっと割合で表すと

• プレゼンテーションレイヤ
  1. 20%
  2. 40%
  3. 9%
• ビジネスロジックレイヤ
  1. 9%
  2. 9%
  3. 9%
• その他
  1. 1%
  2. 1%
  3. 1%
  4. 1%

傾向としてはこんな感じ。対象のシステムの規模や用途によって変わるだろうが、認証と検証で多くを占めるというのは殆どのシステムに共通していることではないだろうか。(Webサーバベースのリッチクライアントの場合データレイヤの機能は持たないので、事の外傾向が強かったのかもしれない)
意外だったのはDIコンテナとAOPの割合の低さだ。
DIコンテナに関しては、プロジェクト配下のクラスは全て自動生成できるような仕組みを提供したので、到るところでオブジェクトファクトリとしてコンテナを使用しているのだが、そもそもDIコンテナ自体が「縁の下の力持ち」「仲介者」的な役どころなので、カスタマイズ時には殆ど出てこない(それが当たり前なのかもしれない)
AOPに関しては以前に日記でも書いたが(※)、現状ではごく一部の自動化目的にしか使われていない。これは何故だろうと考えてみたが、

• パフォーマンスに懸念があるケースでは選択肢から除外される
• 予想される要求に対しては、そもそもAOPにする意味が無い
• Cross-Cutting concernを意識してシステムを設計することが現状、一般的でない

ということでAOPのアプリケーションからの有効利用という点に関しては、まだまだこれからだという感が強い。(むしろこの程度の使用が当たり前だという説もある)

一番手がかかるのが「認証処理」と「検証処理」なのは、今も昔もこれっぽっちも変わっていない。

※ カスタム属性を用いたデータバインディングの省力化(INotifyPropertyChanged実装編)