TERASOLUNA for .NETフレームワーク概説

.NET開発でもオープンソース・フレームワークを使おう

株式会社NTTデータ
技術開発本部 ソフトウェア工学推進センタ 
立見 博史
2008/09/30
Page1 Page2 Page3 Page4

.NETでの業務システム向けフレームワークに必要な“3+1”の条件

 ここでは、.NETでの業務システム向けフレームワークに求められる条件として、機能面から3つと、.NET開発の特性を踏まえて1つを示したいと思います。

  • .NETでの業務システム向けフレームワークに必要な3+1の条件

  • 機能面の3つの条件
    業務システム全体のアーキテクチャを統一する
    複雑な処理を隠ぺいする
    .NET Frameworkでは足りない機能を強化する

  • .NET開発の特性を踏まえた1つの条件
    .NET FrameworkとVisual Studioの仕組みをそのまま利用する

業務システム全体のアーキテクチャを統一する

 .NETの業務システム向けフレームワークに限らず、すべてのフレームワークに共通する必要条件として、システム全体のアーキテクチャを統一することが挙げられます。システム全体で一貫性を持ったアーキテクチャを採用することで、品質の画一化と保守性の向上を狙います。

 「アーキテクチャの統一」というと難しく聞こえるかもしれませんが、要はある処理の呼び出し方をシステム全体で統一するということです。例えば、スマート・クライアント型システムにおけるビジネス・ロジックの呼び出しの流れを考えてみましょう。クライアント・アプリケーションからサーバ上のビジネス・ロジックを呼び出すときの流れは、ほぼ以下のようになると思います。

1. Windowsフォームなどの画面からサーバへ送信するデータを選択
2. 送信データの妥当性の検証(入力値検証)
3. データをサーバへ送信
4. (サーバ側でビジネス・ロジックを実行)
5. ビジネス・ロジックの結果データをサーバから受信
6. 受信したデータを画面へ表示

 このような、クライアント側アプリケーションからのサーバ側ビジネス・ロジックの呼び出し処理において、この「サーバ上のビジネス・ロジックの呼び出し方」を、「1つの定型化した一連の流れ」だけに規定します。そして、それを実現するために有益なコンポーネントを、フレームワークとして提供します。そのコンポーネントをすべての開発者が共有することで、システム全体のアーキテクチャの一貫性を保っていくのです。

 これがアーキテクチャの統一です。クライアント・アプリケーションのどの実装を見てもまったく同じ方法で、サーバ上のビジネス・ロジックを呼び出すことになるため、ある一定の水準の品質を確保することができ、かつ、構造が理解しやすいため、保守性が向上します。

 業務システム向けフレームワークを導入すると「保守性が向上する」と述べましたが、あくまでも保守性向上の一助になるということです。注意しなければならないのは、フレームワークを導入すれば必ず保守性が向上するとは限らないことです。当然、法律改正などの外的要因によって、システム要件が頻繁に変更されるようなところは、後々簡単に対応できるような仕組みのフレームワークにする必要があります。処理の定型化とシステム要件の頻繁な変更に耐え得るように設計されたフレームワークは、業務システム開発において非常に強力なツールとなるでしょう。

複雑な処理を隠ぺいする

 フレームワークの一部として、複雑な処理を隠ぺいする機能を提供することも必要なことです。例で挙げたデータ・アクセス処理、通信処理、非同期処理などは、まさしくその複雑さを隠ぺいした機能としてフレームワークで提供するべきでしょう。複雑な処理を隠ぺいした機能を開発者全員で共有することで、各開発者の作り込みが少なくなり、システム全体の品質向上に役立ちます。

.NET Frameworkでは足りない機能を強化する

 .NET Frameworkではかなり多くの機能が提供されています。たいていのアプリケーション開発であれば、標準で提供されている機能だけでも十分でしょう。しかし、業務システム開発で使うとなると、もう少し気が利いていると嬉しい機能も多くあります。

 例えば、ASP.NETの画面遷移です。通常はResponseクラスのRedirectメソッドを使うと思いますが、このRedirectメソッドのパラメータには、文字列でURLを直接指定しなければなりません。業務システムの開発中で遷移先画面がまだ作成されていない場合、この画面遷移処理が正しく実装できていることを確認するためにはどうしたらよいでしょうか?

 まず、存在しないURLへそのままリダイレクト要求を行う方法が考えられます。通常は存在しないURLへリダイレクト要求を送れば、「画面が見つかりません」というエラー・ページへ遷移してしまうと思います。これでは正常な画面遷移の確認ができません。

 では、Redirectメソッドのパラメータに指定するURLの文字列を一時的に変更して、取りあえずほかのページへリダイレクトすることで確認する方法はどうでしょうか。この方法では、画面遷移の確認のたびにソース・コードを書き直してビルドし直すという作業が入ってしまいます。書き直したソース・コードを元に戻すことを忘れてしまえば、それがそのままバグになってしまいます。

 この例のように、画面間の依存関係が強いことは、業務システム開発においてしばしば問題となります。本当に小規模な開発では気にならないかもしれませんが、画面数が数十から数百となり、複数の開発者が同時に実装を始めるという場合、開発当初からすべての画面が存在しているということはほぼ不可能です。遷移先画面を変えるだけですべてのソース・コードをビルドし直さないとならないというのは、あまり現実的ではありません。ビルドし直すことなく、遷移先画面を自由に変更できたらいいのに、と筆者は思ってしまいます。

 このように、小規模開発では.NET Frameworkの標準機能を使っても問題にならないことでも、比較的大規模な業務システム開発で使うとなると使いづらい機能がいくつかあると思います。このような機能を業務システム向けフレームワークとして強化してあげることが必要なのです。

.NET FrameworkとVisual Studioの仕組みをそのまま利用する

 ここまでは、業務システム向けフレームワークには「業務システム全体のアーキテクチャを統一する」「複雑な処理を隠ぺいする」「.NET Frameworkでは足りない機能を強化する」ことが必要だと述べてきました。しかし、最後に非常に重要だと考えていることがあります。それが「.NET FrameworkとVisual Studioの仕組みをそのまま利用する」ということです。

 もともと、.NETにはWindowsフォームやASP.NETという優秀なフレームワークがあり、Visual Studioと連携した開発生産性の高い仕組みが最初から提供されています。その仕組みを利用しない手はありません。何も、自分でまったく新しいフレームワークを作り上げる必要はないのです。

 なぜかというと、Visual StudioはWindowsフォームやASP.NETでの開発に適した形で提供されており、その生産性を超えるような新たな仕組みと開発補助ツールを整備することは非常に大変だからです。さらに、WindowsフォームやASP.NETの仕組みをそのまま利用することで、業務システム向けフレームワークの学習コストを下げるという効果も期待できます。一般的な.NETの技術を学んだ開発者のスキルを、業務システム向けフレームワークを使った開発でもそのまま生かすことができるに越したことはありません。

 このように、.NETで業務システム向けフレームワークを整備するときには、WindowsフォームやASP.NETといった既存の仕組みをそのまま生かせるような形態で提供することが理想的でしょう。

 以上、.NETでの業務システム向けフレームワークに求められる条件を述べてきました。最初に述べた機能面の3つの条件「業務システム全体のアーキテクチャを統一する」「複雑な処理を隠ぺいする」「.NET Frameworkでは足りない機能を強化する」は、どの開発言語のフレームワークでも共通していえることだと思います。さらに.NETにおける業務システム向けフレームワークを整備するときは、ぜひ、.NET開発の特性を踏まえた1つの条件で述べた「.NET FrameworkとVisual Studioの仕組みをそのまま利用する」ということを意識してみてください。開発者のみんなが慣れた形態でフレームワークとして提供することも、非常に重要な要素だと思います。

.NET界のオープンソース・フレームワーク

 さて、ここまでは.NETでの業務システム開発におけるフレームワークの必要性と、そのフレームワークに必要な条件について述べてきました。もちろん.NETの世界にもオープンソースとして提供されているフレームワークはいくつかあります。例えば以下のものです*1

*1 このほか、「業務システム全体のアーキテクチャを統一する」ものではありませんが、「Seasar.NET」や「NHibernate」などJavaから移植されたオープンソース・フレームワークもあります。

 しかし現時点では、まだ.NET業界スタンダードといえるようなフレームワークは存在しないと思います。上記のフレームワークのうちEnterprise Libraryについては、@IT/Insider.NET上にすでに記事群があります。以降では、TERASOLUNA for .NETについて、その内容を手短に紹介していきます。


 INDEX
  [TERASOLUNA for .NETフレームワーク概説]
  .NET開発でもオープンソース・フレームワークを使おう
    1..NET Frameworkだけの業務システム開発で起こり得る問題
  2..NETでの業務システム向けフレームワークに必要な“3+1”の条件
    3.オープンソース・フレームワーク「TERASOLUNA for .NET」とは?
    4.「TERASOLUNA for .NET」のサーバ側の特徴と機能

インデックス・ページヘ  「TERASOLUNA for .NETフレームワーク概説」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間