データバインディングを利用したアプリケーション開発で、双方向バインディング（View→DataSourceおよびDataSource→Viewに変更を通知)を実現するためデータソースとなるオブジェクトにINotifyPropertyChanged を実装する方法がああります。そのための基本的な方法は各プロパティのセッターでPropertyChangedイベントを発生させるコードを記述することです。

1
2
3
4
5
6
7
8
9
10
11
12
13

int testProperty;

  public int TestProperty
  {
    get { return testProperty; }
    set
    {
      if (value != testProperty) {
        testProperty = value;
        OnPropertyChanged(new PropertyChangedEventArgs("TestProperty"));
      }
    }
  }

この方法の問題点は

• 記述量が多く、時間の掛かる単純作業となること
• ドメインコード(アプリケーション固有コード)とインフラストラクチャコードが混在すること

です。単純作業はスニペット・T4テンプレート・コードジェネレーションなどの方法で回避できます。

ドメインの記述の自由度を保つためにはなるべくインフラストラクチャの制限を受けたくありません。POCOエンティティが見直されているのはそのためだと理解しています。ドメインコードとINotifyPropertyChangedを実現するコードを分離するため、MicrosoftのUnity依存性注入コンテナを使うことが考えられます(下記コード参照)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Reflection;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.InterceptionExtension;

namespace UnityAdditionalInterfaceTest
{
  class NotifyPropertyChangedBehavior : IInterceptionBehavior
  {
    static readonly MethodInfo addPropertyChangedMethodInfo = 
      typeof(INotifyPropertyChanged).GetMethod("add_PropertyChanged");
    static readonly MethodInfo removePropertyChangedMethodInfo = 
      typeof(INotifyPropertyChanged).GetMethod("remove_PropertyChanged");

    public object Target { get; set; }

    event PropertyChangedEventHandler PropertyChanged;

    void RaisePropertyChanged(string name)
    {
      if (PropertyChanged != null) PropertyChanged(Target, new PropertyChangedEventArgs(name));
    }

    public IEnumerable<Type> GetRequiredInterfaces()
    {
      return Type.EmptyTypes;
    }

    public IMethodReturn Invoke(IMethodInvocation input, GetNextInterceptionBehaviorDelegate getNext)
    {
      if (input.MethodBase == addPropertyChangedMethodInfo) {
        PropertyChanged += (PropertyChangedEventHandler)input.Arguments[0];
        return input.CreateMethodReturn(null);
      } else if (input.MethodBase == removePropertyChangedMethodInfo) {
        PropertyChanged -= (PropertyChangedEventHandler)input.Arguments[0];
        return input.CreateMethodReturn(null);
      } else if (input.MethodBase.Name.StartsWith("set_")) { //プロパティ設定
        RaisePropertyChanged(input.MethodBase.Name.Substring(4));
      }
      return getNext()(input, getNext);
    }

    public bool WillExecute
    {
      get { return true; }
    }
  }

  public class Person
  {
    public virtual string Name { get; set; }
    public virtual int Age { get; set; }
  }

  public static class Program
  {
    static void AcceptNotifyPropertyChanged(object sender, PropertyChangedEventArgs e)
    {
      Console.WriteLine("NotifyPropertyChangedOccured:" + e.PropertyName);
    }

    public static void Main()
    {
      var behavior = new NotifyPropertyChangedBehavior();
      var target = Intercept.NewInstanceWithAdditionalInterfaces<Person>
        (new VirtualMethodInterceptor(), 
        new IInterceptionBehavior[] { behavior }, 
        new[] { typeof(INotifyPropertyChanged) }, new object[] { });
      behavior.Target = target;
      (target as INotifyPropertyChanged).PropertyChanged += AcceptNotifyPropertyChanged;
      target.Name = "test";
      target.Age = 1;
      Console.ReadKey();
    }
  }
}

PersonはDataSourceに指定するエンティティ、NotifyPropertyChangedBehaviorクラスはINotifyPropertyChangedを実現するクラスです。Personは自動実装プロパティを使用していて単純な記述になっています。またセッターに割り込むためにvirtualを付けています。Intercept.NewInstanceWithAdditionalInterfaces<Person>を使ってインスタンスを作成すると、元のクラスがインタフェースを実装していないにもかかわらず、実装しているかのように扱うことができます。特定の基本クラスを必要としませんので、インフラストラクチャコードを気にしないで継承を使用できます。また表示用には直接Personのコンストラクタを呼び出し、編集用にはUnityを使ってインスタンスを作成するといった使い分けをすることもできます。

上記コードではエンティティ内でプロパティ変更時アクションを記述する場所がありませんので、外部から使用するのと同様にイベントハンドラを追加するか、特定の名前のメソッドを決めておきプロパティ変更時に呼び出すなどの工夫が必要になります。

ドメインロジックとは

エンタープライズアプリケーションアーキテクチャ(マーチンファウラー著)を読むとドメインロジックという言葉が出てきます。ドメインロジックとはアプリ-ケーションが扱う問題領域の論理であると私なりに理解しています。例えば販売管理で請求額の計算など規模の大きい物や、数量と単価からの金額計算などの小さな物までがこれに含みます。画面遷移・変数の画面表示・データベースの更新等はこれに含みません。ドメインロジックは当方のWindows Formsのアーキテクチャではドメイン層に記述します。

ドメイン層のデータ構造

データベースは表形式でデータを持っています。それに対しドメイン層ではオブジェクトグラフ形式でデータを持っています。テーブルはエンティティ（参照オブジェクト）で表します。エンティティ間の関連は参照で表します。

例えばデータベース上に伝票・得意先マスタ・伝票明細テーブルがあったとします。ドメイン層では伝票エンティティに得意先マスタを参照するプロパティと伝票明細のリストを保持するプロパティを持たせています。

エンティティは、固定繰り返しを持つ場合など、必要に応じて値オブジェクトによって複合的な構成にする場合があります。

ドメインロジックパターンの分類

ドメインロジックの書き方について、トランザクションスクリプト・ドメインモデル・テーブルモジュールがあります。これらの違いは以下の通りです。

ドメインロジックパターンの適用

当方では従来主にトランザクションスクリプトで記述していました。今はドメインモデルとテーブルモジュールを併用しています。行内の処理およびエンティティが保持する子エンティティの集計処理はドメインモデルで、ルートエンティティの集計処理、例えば複数行の金額合計計算などはテーブルモジュールで記述しています。伝票と伝票明細を編集することを想定した場合には、伝票明細の金額を合計して伝票の合計金額項目を更新する処理は伝票に記述しています。

パターンを変更した理由はトランザクションスクリプトだと処理の重複が発生しやすいからです。ドメインモデルとテーブルモジュールを使った場合１つの処理だけを見れば処理が分散して複雑になるのですが、アプリケーション全体で見ると重複が少なくなりどこに何が書いてあるか見通しが良くなります。

ドメインロジックの構成

当方ではドメインロジックを下記のもので構成しています。

エンティティの選択

エンティティは次の３種類に分けることができます。

• データベーステーブルに対応するエンティティ
• テーブルと異なる結果セットを持つクエリーに対応するエンティティ
• 抽出条件等ユーザー入力に必要なエンティティ

クエリーに対応するエンティティについて補足説明します。ドメイン層はオブジェクトグラフでデータを保持していますので必要なクエリーを削減することができます。例として伝票一覧に得意先マスタの項目である得意先名を表示することを想定します。件数の少ないマスタ類は参照されたときに全件ロードするようにしてあります。そのため得意先名は伝票.得意先マスタ.得意先名で参照できるのでテーブルを結合する必要はありません。伝票-伝票明細といったトランザクションテーブル同士の結合および集計を伴う場合にクエリーに対応するエンティティを作成します。

リポジトリの役割

リポジトリでは、クエリーによるエンティティのロードと更新処理を行います。

キーを指定して該当するエンティティをリストにロードする場合、呼び出し元コードはリポジトリに対しExtractByKey(Key)を呼び出します。リポジトリはクエリーを発行し、その結果をIEnumerableで返します。呼び出し元コードこれを所定のリストに格納します。

抽出条件をユーザが指定できる一覧画面では、抽出条件エンティティのGetFilterExpressionを呼び出して、入力された抽出条件を元にExpression型の条件式を作成します。条件式はExpression Tree によるDSLで表現しています。この条件式をリポジトリのExtractメソッドの引数に指定して呼び出します。ExtractメソッドはIEnumerableの形式でエンティティを取得します。

リポジトリではSQLを利用しながらドメインロジックを実現する場合があります。例えば請求一覧表を作成する処理を大雑把に説明すると、まず各得意先について売上・入金の合計を計算して差額を出します。このときの合計計算はSQLを利用し、その結果はデータベース上のテンポラリテーブルに書き込みます。テンポラリテーブルをロードして請求一覧表とします。これら一連の処理は請求一覧リポジトリに記述しています。SQLを利用する利点はSQLによる簡潔な記述が活かせること、通信量が少ないこと、パフォーマンスがよいことです。欠点はデータベースエンジンによってSQLの記述が異なる場合があること、ドメインロジック内にSQLによる処理とオンメモリテーブル上の処理が混在してしまうことです。

データベースを利用したアプリケーション開発で、ユーザの入力した条件に従って抽出する場合など、SQLを動的に作成して発行しなければならない場合があります。そのようなときクエリーオブジェクトを使っていました。クエリーオブジェクトはSQLの文字列作成をラップしたオブジェクトで、例えば次の様な記述になります。

1
2
3
4
5
6

var query = new Query();
query.Select.Add(伝票);
query.Select.Add(new SqlColumn("Coalesce(", 顧客マスタ.住所１Column, ",) || Coalesce(", 顧客マスタ.住所２Column, ",");
query.From = new SqlFrom(伝票).InnerJoin(顧客マスタ).On(伝票.顧客コードColumn, 顧客マスタ.顧客コードColumn);
query.Where.Add(伝票.顧客コードColumn, MatchKind.Equal, ConditionRow.顧客コード);
query.Where.Add(伝票.仮伝票Column, MatchKind.NotEqual, true);

queryはクエリーオブジェクトでSelect,From,Whereなどの各句に適したビルダーをメンバーに持ちます。ConditionRowはユーザが入力した抽出条件を表すオブジェクトです。この方法での問題点は記述量が多いことと、型付きデータセットのメリットを活かせないこと、データベース関数への対応が難しく、その部分だけ文字列の組み立てが必要になるなどです。

解決策をなかなか見つけられずにいましたがExpression TreeによるDSL処理系を開発すれば解決できることがわかりました。

例えば上記のクエリーオブジェクトと同等の記述は次のようになります。

1
2
3

var query = new Query(() => SqlExp.Select(伝票.AllColumns, ((顧客マスタ.住所１ ?? "") + (顧客マスタ.住所２ ?? "")).As(住所))
  .From(伝票).InnerJoin(顧客マスタ).On(伝票.顧客コード == 顧客マスタ.顧客コード)
  .Where(伝票.顧客コード == ConditionRow.顧客コード && !伝票.仮伝票));

Expression Treeを応用したフレームワークLinq To SQLは標準クエリー演算子と仕様が合わせられています。それに対して当方が取り組んだDSL(SqlExpと命名)はSQL文との互換性を重視しています。ラムダ式を組み合わせてクエリーを表現するLinq To SQL とは違い、１つのラムダ式でクエリーを表現します。また、SELECT文だけでなくINSERT, UPDATE, DELETE文も表現できます。

SqlExp処理系は、与えられたラムダを解釈しExpression TreeをたどってSQLを作成します。

Expression Treeではメソッド名・プロパティ名を取得することもできますし、実行時にコンパイルして値を取得することもできます。伝票・顧客マスタ・住所１等のテーブル名・カラム名はそのまま文字列に変換し、ユーザが入力したConditionRow.顧客コード等は値を取得してから文字列に変換します。テーブル名・カラム名はスキーマに基づいてコード生成しています。DSL中に表われるSelect,As,From,InnerJoin等のメソッドは実装する必要がなく単なるダミーです。SqlExp処理系でそれらをSQL文字列に変換できればよいのです。また、データベース関数を処理できるように作っています。新たなデータベース関数に対応したい場合には名前と引数リストを合わせたダミーのメソッドを作れば良いだけですので機能を簡単に拡張できます。動的な追加はクエリーオブジェクトと同様に各句のビルダーを使います。ビルダーは文字列ではなくExpression Treeを保持するようにしています。ビルダーをSqlExp上の挿入したい位置に記述することでビルダーの持っている部分式を展開するようにしています。

1
2
3
4

var columns = new SqlColumns();
columns.Add(() => 伝票.伝票番号);
columns.Add(() => 伝票.仮伝票);
var query = new Query(() => SqlExp.Select(columns).From(伝票));

工夫した点としては、比較演算の一方がnullであれば演算自体を消去していることです。抽出条件はユーザが入力しなければ条件に含めないことが多いのですが、そのような場合にも条件分岐を記述する必要がありません。

SqlExp処理系を開発することで下記メリットを得られました。

• 記述が簡潔になった
• タイプミスはコンパイル時に気づく
• データベース関数対応等容易に拡張できるようになった

今のところ開発プロジェクトで使用するDMLをすべて表現できています。

SqlExp処理系開発に際して、Expression Treeについて書いておられるあちらこちらのサイトを参考にさせていただきました。

DBMSのトランザクションを使うと中途半端な状態でデータが登録されることを防げます。例えば会計システムで借方・貸方の順にデータを登録し、貸方登録時にエラーが発生したら借方の登録がキャンセルされます。

1つのデータベース・1つのシステムで完結するときはトランザクションが有効に機能します。既存パッケージと連係するようなシステムでパッケージ側のAPIがトランザクションを備えていないと対策が必要になります。

弥生販売管理ではAPIが用意されていて、例えば外部システムで作業指示書発行し、売上計上したら弥生にも同時に売上登録することができます。弥生APIにはトランザクションを直接使用する機能はないので、処理順序を工夫します。

• 外部システムでトランザクション開始
• 外部システムを更新
• 弥生APIで弥生側を更新
• 外部システムでトランザクションコミット

このような順序にすると、３での弥生側の更新段階でエラーが発生すれば２での外部システムの更新もキャンセルされますので矛盾したデータが登録されることはありません。

但し３の段階でAPIを複数回呼び出して更新しなければいけないような複雑なシナリオでは、トランザクションによって矛盾したデータの登録を防ぐことはできません。弥生APIでトランザクションをサポートしてくれるとこのような場合にも対応できるようになります。

私はPHPを開発に使用するまでにはVB, C#, rubyなどを使ってきました。

PHPを使って勘違いなどで思うような動作にならずに手こずった点や、勘違いしそうだなと思う点を挙げてみます。

switchによる比較がifによる比較と異なる?

PHPでは等しいを表す比較演算子に 緩やかな比較==と厳密な比較===があります。==は、型変換をした上で比較します。===は型が異なると不一致となります。switchでは==に相当する比較をしますので、swicth($a) case 1: と書けば、$aが文字列の'1'でも一致します。

セッションにオブジェクトを保存するのにシリアライズする必要はない

$_SESSION['test'] = new Test();とそのまま代入すればよいです。セッションファイルの中身を見ればわかりますが、serialize()でシリアライズしたのと同じ形式で保存されます。これははまりどころというよりは他のサイトでserialize関数を呼び出すと書いてあるのを見かけましたので。

旧バージョンでセッションに日付型が保存できない

PHPのバージョンによってはDateTimeをセッションに保存できません。組み込み型は当方手持ちですと5.3.8は保存でき、5.2.14は保存できませんでした。serialize関数のマニュアルにはPHP の組み込みオブジェクトの多くはシリアル化できないことに注意しましょう。 と書いてあります。

データベースのNumberに相当する型がない

Floatで代用すると小数部の計算で誤差が出ます。bcで始まる関数群を使えば誤差無しの演算ができるのですが、標準ではインストールされないのでレンタルサーバではこれらが使えない場合があります。

リファレンスを作成すると元の変数までリファレンスになる

1
2
3
4
5
6
7

$a = array();
$a['x'] = 'x';
$ref = &$a['x']; //この行の有無で結果が変わる
$b = $a;
$b['x'] = 'y';
var_dump($a);
var_dump($b);

リファレンスは変数にエイリアスを設定できる物で使い方によっては大変便利な物です。しかしときには想像しがたい動作をします。配列$aのキー'x'に'x'をセットし、配列$aを$bに代入後、同じキーに'y'を代入する物です。３行目におまじないがあり$a['x']への参照を設定しています。これがなければ$a['x']='x',$b['x']='y'となります。コピーオンライトが効いていると言うことです。しかし一見無関係に見える３行目を挿入すると$a['x']='y',$b['x']='y'となります。要素がリファレンスを持ったまま配列をコピーすると該当要素のコピー元とコピー先でエイリアスになってしまうようです。オブジェクトのフィールドにも同じことが言えます。

PHPでの開発では、以前は秀丸を使っていましたが今はNetBeansを使っています。同じコードを作るのにNetBeansなどのIDEを使用することによって生産性が向上します。ここではさらに踏み込んでIDEの機能を利用することを前提にアーキテクチャを変えた例を紹介します。

以前は、PHPが動的型付け言語なのでクラスメンバーに応じたメンバー名の補完はできない物と思っていました。ですからReflectionパターン考察で触れたように、データベーステーブルの行などのエンティティはクラスで表現するのではなく、項目名をキーに持つ連想配列として扱っていました。

NetBeansではメンバー名をほぼ正確にリストアップし、コード補完してくれます。

1
2
3
4
5
6
7
8
9
10
11

/**
 * 関数の説明
 * @param type $param 
 */
function functionName($param) {
  $param-> <i>コード補完有効</i> 
  $varname1 = new TestClass();
  $varname1-> <i>コード補完有効</i> 
  /* @var $varname2 type */
  $varname2-> <i>コード補完有効</i> 
}

関数にPHPDoc形式でコメントを書いた場合には引数の型を認識してくれます。エディタで/**<Enter>と入力するとドキュメントコメントの雛形を作ってくれるので、コメント作成の手間を減らしてくれます。右の例で@param type paramのtypeの部分を適切な型名に置き換えれば良いのです。

また、コンストラクタ呼び出しの結果を代入した変数も型を認識してくれます。

それ以外の部分で型を認識させたい場合は、/* @var $varname type */の形式でコメントを書きます。

IDEのコード補完を使用することを前提にエンティティをクラスで表現すれば開発効率をもっと上げることができると期待できます。

実際にやってみると次のような効果が出ました。

• 単純な綴りの間違いや、勘違いによって存在しない項目にアクセスするミスを大幅に減らせた
• メンバーにコメントを書いておけばコントロールキーを押しながらクリックすることでコメントが表示されるので仕様確認が簡単になった
• メンバー記述後に定義部分にジャンプできるので定義部の修正が楽になった
• コメントを書くことによるメリットが大きいのでこまめにコメントを書くようになった

注意点としては、データベースから読み取りや$_POSTなどのリクエストパラメータは連想配列形式になっているので、クラス形式への変換が必要となることです。このような変換は単純作業なのでツールを作成してコードジェネレーションしています。このとき各項目はそのデータ型に合わせて文字列・数値・日付等に型変換を行うことで型の不一致による不具合を避けています。

アーキテクチャを変更することで改めてIDEのありがたさを実感しました。

複数の開発者が作成したコードをマージしたり、仕様が一部異なる複数のプロジェクトに共通の変更を加えたりするときに、手間なく正確に作業するにはバージョン管理システムが役に立ちます。数年前からバージョン管理システムのSubversion(TortoiseSVN)を使ってきましたが、今回Mercirual(TortoiseHg)を試しました。

リポジトリ・コミット・マージ

変更履歴を記録してあるデータストアをリポジトリと呼びます。コミットでその時点のスナップショットをリポジトリに保存します。このときリビジョンが刻まれ、必要があれば簡単に任意のリビジョンに戻すことができます。

バージョン管理で重要な機能がマージです。マージは複数箇所での変更を１つのまとめる機能です。異なる開発者の変更をまとめるときや、あるプロジェクトに加えた変更を仕様が一部異なる別のプロジェクトに適用するときにマージが発生します。ファイルをプロジェクトに追加しても自動的にマージしてくれるのはもちろんのこと、同じファイルを変更した場合にも変更を加えた行が隣り合っていなければ自動でマージしてくれます。隣り合っているか同一行を変更した場合は競合が発生し、競合解消用のエディタによって手動でマージします。

集中型・分散型

Subversionはリポジトリを１カ所で持つ集中型と呼ばれる物で、それに対してMercirualはリポジトリを複数持つことができる分散型と呼ばれる物です。開発者それぞれがコーディングのスクラップアンドビルドするときに自分用のリポジトリを利用すれば他の開発者に影響を与えません。これが分散型のメリットです。Mercurialの他にGit、Bazaarなどがあります。

当方は開発規模が小さいので集中型のSubversionでも十分なのですが、Mercurialに備わっているRebase, Transplant, Splitが仕様が一部異なる複数のプロジェクトを管理するのに便利に使えることがわかりました。

ブランチ

一部仕様の異なる複数のプロジェクトはブランチという機能を使って管理します。メインで開発するブランチをSubversionではtrunkという名前を付ける習慣になっているようです。trunkでの変更を別のブランチにも適用するとき、Subversionではリビジョンの範囲をマージという機能を使います。更新→マージ→動作確認→コミットの順で操作します。どこまでのリビジョンをブランチに適用したかSubversionが把握してくれているので、いちいちマージするリビジョンを指定する必要はありません。ブランチで変更した結果をtrunkに反映する際にもリビジョンの範囲をマージを使います。但し、相互にマージする場合は、相手方のブランチでの変更だけをマージするためリビジョンの範囲を明示的に指定します。マージ結果をコミットしたリビジョンまでマージしてしまうと同じ更新を２度コミットすることになり、競合が発生します。

リビジョンの範囲をマージを使うと２つのブランチがそれぞれの更新を他方のブランチにマージする形でリビジョンが成長していきます。

Mercurial

MercurialのRebaseはこれとはことなりブランチの分岐点を変えることによって共通の変更を他のブランチに適用します。つまりdefault(Subversionのtrunkに相当)とブランチの差違を最後に適用したことにできるのです。逆にブランチに加えた変更をdefaultに適用するときはTransplantによってdefaultに適用したことにして、Splitによってブランチに適用した変更を取り消し、Rebaseします。

リビジョンの成長過程はリビジョングラフによって確認できますが、リビジョングラフがシンプルでわかりやすいものになり、私はこの方法が気に入りました。

Mercurialは日本語ファイル名の扱いに難があり、win32mbcsエクステンションを使用し、一部のDLLを入れ替えなければなりません。

私は下記URLを参考に設定しました。

http://www.asukaze.net/etc/vcs/hg-fixutf8.html

しかし、Transplant実行時に日本語ファイル名が原因でエラーが出てしまいました。当初想定した使い方ができないので今のところSubVersionを継続使用するつもりです。

mercurial 2.0 では上記の不具合が解消されているようです。win32mbcsエクステンションは必要ですがDLLの入れ替えは不要になっているようです。時間を掛けて検証していないので見落としがある可能性があります。次回新たなプロジェクトが立ち上がったら使ってみます。

Git

久しぶりに見返しましたが、この記事を書いたときから状況が変わりました。Visual Studio にも最初から Git がついています。現在ではもっぱら Git を使用しています。

当方がデータベースアプリケーションをWindows Formsで作成するときのアーキテクチャーを紹介します。

レイヤー間の連係

各レイヤー間の連係は下図のようにしています。

データバインディングではViewからドメイン層のエンティティに直接バインディングしています。

コマンド実行では各層で必要があれば下層を呼び出しています。

各層は、Reflectionパターンのベースレベルまたはメタレベルで記述します。ドメイン層ではベースレベルで記述、すなわちエンティティのプロパティをそのまま使用します。Viewやデータアクセス層はメタレベルで記述、Viewでは入力部品やDataGridViewColumnがプロパティを表します。データアクセス層ではカラムオブジェクトがプロパティを表します。

データのロードはリポジトリを通じて行います。データベースの更新はUnit of Work によって行います。XMLやテキストファイルへの保存はリポジトリを通じて行います。

リポジトリにはクエリーを記述しメソッドによって呼び出せるようにします。伝票－伝票明細のような構造を持つ場合、関係表構造(IDataReader)からオブジェクトグラフへの変換(R/O変換)は汎用ライブラリを利用してリポジトリ内で行っています。

画面の継承関係

画面はメニュー・一覧・編集といった風にある程度パターン化しています。それぞれパターンには共通の処理がありますのでこれらをベースクラスに記述し、具象画面は派生クラスに記述します。Viewではもっぱらデザインでの継承階層、アプリケーション層ではメニュー・一覧・編集といった機能による継承階層を持たせています。

これによって各具象画面のコードは少なくなります。単純なCRUDだけですとView側に自分で記述するコードはありません。アプリケーション層もほとんど記述はありません。

画面遷移

画面遷移はModel側のアプリケーション層で管理します。ViewはModelに追従して画面遷移を行います。

下図でCallerModelは遷移元Model、CalllerFormは遷移元View、BaseModelはModelの共通の基本クラス(ここではstaticメソッドを表現)、CalleeModelは遷移先Model、CalleeFormは遷移先Viewです。

遷移元Modelが遷移先Modelの型とオプションを指定してstaticメソッドOpenModelを呼び、それに従ってCalleeModelを作成・初期化します。既に作成済みであれば再利用します。作成済みModelはグローバルなDictionaryによって管理しています。コンストラクタと初期化メソッドを分けているのはメソッドのオーバーライドによって初期化処理を柔軟に実装したいからです。

初期化が終わると、遷移先ModelのCallerプロパティに遷移元Modelを設定し、遷移先Modelでは遷移元ModelのAddCalleeを呼び出します。これを受けて遷移元Modelでは対応する遷移元Viewに対して、CallerAddedによって遷移先Modelが追加されたことを通知します。遷移元Viewは追加された遷移先Modelに対応する遷移先Viewを生成します。作成するViewは一定の規則でModel名からView名を導き出してリフレクションによって作成します。以上で遷移先ModelとViewの作成が完了し、次に遷移先ModelのRunメソッドを実行してModelとしての最初の動作を実行します。通常は対応するViewに対してShowを通知し、表示を促します。

このシーケンスですと画面間のデータの受け渡しは、Model同士で直接行いますのでViewを通じて受け渡すよりもシンプルになります。

対話型システムのアーキテクチャとして代表的なものにMVCがあります。そしてMVC以外にもさまざまなアーキテクチャがあります。それらのアーキテクチャ間で用語が違っているなど理解しにくかったので、自分が理解している範囲でまとめてみました。仲間達と書きましたが全く異なる視点で設計されているものもあります。

MVC(Model-View-Control)

アプリケーションをControl(入力)-Model(処理)-View(出力)に分割する。Modelをデータと捉えるとControlにビジネスロジックを書くことになりうまく分割できない。命名が誤解しやすい。データバインディング・Observerパターンを使うとModelからViewの更新はControlの補助無しに行われる。Webのサーバ側アプリケーションやWindows Formsでもデータバインディング・Observerパターンを使えない処理ではControlがViewを呼び出す。

Document-View

MVCのMがDocument、VCがViewに相当する。Windows Forms 等ではキーボード・マウス入力の大半を自動で処理してくれるので、独立したControlが必要になることはあまりない。そのようなUIではMVCのVCが一体化したDocument-Viewが向いていると思われる。

PAC(Presentation-Abstraction-Control)

アプリ－ケーションを複数のエージェントに分けて管理する。１つのエージェントはPresentation(入出力)-Control(処理)-Abstraction(データ)からなる。エージェント同士の独立性を保つことを重視していると思われる。エージェント間はControlを通じて細いインターフェースでやりとりする。プラグインを実装する、異なるプロセスで協調動作する、異なるマシンで協調動作するなどの用途に向いていると思われる。

BCE(Boundary-Control-Entity)

アプリケーション開発のロバストネス分析過程で用いられる。Boundary(入出力)-Control(処理)-Entity(データ)に分割する。処理をどのEntityに持たせるべきかを検討する場合にも用いられるので、できあがったソフトウェアの構造がBCEに分離しているわけではない。

MVVM(Model-View-ViewModel)

WPF、Silverlightで用いられている。View(入出力)-ViewModel(View用の処理)-Model(Viewに特化しない処理)。

Windows Formsの開発ではDocument-Viewを使っています。View上のボタン使用可／不可の状態はModelで管理し、ObserverパターンでViewを更新しています。画面遷移はModelが遷移先のModelを作成することで行っています。レイヤーアーキテクチャによってModelはさらに複数の層に分けています。

PHPによるWebアプリケーションではMVCを使っています。Controlはページ毎に持っていて、ページへの要求の解釈、Modelの呼び出し、ビューの呼び出しを行っています。Modelは各種更新処理、表示用のデータロードを行っています。Viewではテンプレートにデータを渡して、HTMLを組み立てます。

どちらにしてもModelにはViewへの参照は持たないもののViewを意識した処理を行っています。

ViewとModelを分離しなかった場合、同じロジックを複数の画面で使いたい場合に、ロジックが入力部品と結びついているため再利用が困難です。最小限ViewとModelを分離するとこのようなことが防げます。

これらのアーキテクチャを採用することで、アプリケーションに秩序が生まれ、どこに何が書いてあるかわかりやすく、生産性・保守性が上がる点がメリットであると考えています。

Visual Studio 2010ではC#にdynamicが追加されました。

JavaScript, php, rubyの様に実行時に型を解決しメソッドをバインド(レイトバインディング)するものです。Visual Basicでは以前からソース毎にレイトバインディングすることを指定できましたが、c#のdynamicでは変数毎に指定できるのです。

現状のC#の言語仕様では残念ながら型のつじつま合わせのためのコードを書かなければなりません。これを部分的に軽減するためにdynamicが使えます。

オープンジェネリックメソッド呼び出し

例えば、型引数を持ったクラスBase<T>のメソッドMethod1を他のクラスから呼び出そうとしても、型引数が決まらない(オープンジェネリック型)ためにキャストできないので呼び出せないのです。オープンジェネリック型のメソッドを呼び出そうとする場合には、リフレクションを使用する方法の他に、型引数を持たないBase<T>の基底クラスBaseを作成してMethod1を仮想メソッドとして持たせ間接的にBase<T>のMethod1を呼び出す方法があります。Netframeworkにもこのパターンはよく現れます。恐らくVisual Studio 2008までの場合は、この方法がベストプラクティスと思われます。この方法の欠点は型のつじつま合わせのためだけに２つのクラスを作らなければならないことです。そしてコーディング量が大変増えてしまいます。

オープンジェネリック型変数の宣言にdynamicを使えば基底クラスを作らなくてもメソッド呼び出しができるようになります。欠点としてはコンパイル時型チェックが効かなくなることです。

今後C#の言語仕様が改善されて共変・反変の機能が強力にサポートされ、dynamicを使わなくてもオープンジェネリック型メソッドを呼ぶことができるようになることを期待します。

Visitorパターン代替

Visitorパターンでは、Visitorが、継承されたそれぞれのAcceptorのAcceptメソッドを呼ぶと、Acceptorの型に応じたVisitor.Visitメソッドを呼び返します。この仕組みをdynamicで実現すれば、AcceptorのAcceptを経由しないでディスパッチできます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

class BaseItem
{
}

class Leaf : BaseItem
{
}

class Node : BaseItem
{
  public List<BaseItem> Branch { get; private set; }

  public Node()
  {
    Branch = new List<BaseItem>();
  }
}

class Visitor
{
  public void Visit(Leaf item)
  {
    //何らかの処理
  }

  public void Visit(Node item)
  {
    //何らかの処理
    foreach (var child in item.Branch) {
      CallVisit(child);
    }
  }

  public void CallVisit(dynamic item)
  {
    Visit(item);
  }
}

注意点

dynamicで宣言された変数を通してメソッドを呼ぶときに引数に変数を指定した場合、変数宣言の型でメソッドがディスパッチされるか、変数に格納された値の型でディスパッチされる値の型でディスパッチされるか配慮しなければならないことがあります。

1
2
3

dynamic callee = new Callee();
object arg = "TestString";
callee.Method(arg);	  

例えば上の例ではメソッドに渡される引数はobjectで宣言されていますが、変数に代入されている値はstringです。この場合、void Method(string param)とvoid Method(object param)のどちらが呼び出されるかと言うことです。

答えは変数宣言の型でメソッドがディスパッチされるです。この場合はvoid Method(object param)が呼び出されます。これを間違いvoid Method(object param)を用意しなければ最も適しているオーバーロード メソッドには無効な引数がいくつか含まれていますとのエラーが発生します。

変数に格納された値の型でディスパッチして欲しい場合は変数宣言もdynamicにします。

1
2
3

dynamic callee = new Callee();
dynamic arg = "TestString";
callee.Method(arg);