SPREAD for WPFの選定理由について
SPREAD for WPFを選定した理由の本質は、本システムでWPFを選択した理由と実のところ同じです。
- 高いユーザ操作性を低コストで実現可能
- 高い技術的安定性
WPFは非常に高い自由度をもったユーザーインターフェースフレームワークなので、突き詰めればすべて自作することで最高のユーザーインターフェースを実現できるでしょう。しかし常に無制限にコストや期間が掛けられるわけでもありません。
また、エンタープライズ向けのアプリケーションの場合、求められる操作性はある程度想定可能であり、それほど突飛なものは求められないことが多いでしょう。このため、ユーザ操作性と生産性を高いレベルで両立するために、サードパーティーのユーザーインターフェースコントロールを採用することは、非常に有効な手段です。
実際に少し、今回採用したSPREAD for WPFを見ていただこうと思います。
まず、グリッド上で表示・編集するオブジェクトとして次のようなシンプルな従業員クラスを用意しました。
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime Birthday { get; set; }
public int Salary { get; set; }
public bool IsManager { get; set; }
}
これを次のように、SPREAD for WPFのグリッドへ単純にバインドします。行の追加だけプロパティで有効にしています。
<sg:GcSpreadGrid ItemsSource="{Binding Employees}" CanUserAddRows="True"/>
ではこのコードを動かしてみましょう。
EmployeeオブジェクトのListをバインドしただけですが、boolはチェックボックスに、DateTimeはカレンダー選択も入力も可能なコントロールに、数値は数値以外入力できず、入力中も適切にカンマフォーマットが適用されたテキストボックスになっています。
芸が細かいことに、日付入力で月の入力タイミングに5を入力しただけで、ちゃんと5月に確定されています。
もちろん、グリッドは細かい調整が可能です。通常のWPFのようにXAMLで記述したり、コードビハインドのC#コードでカスタマイズすることもできますが、専用のデザイナーで編集することも可能です。
次の画像がデザイナー画面になります。全ての列をソートとフィルタリング可能なようにカスタマイズし、Salary欄の入力値を0～1,000,000に制限するように編集しています。
SPREAD for WPFはExcelライクな操作感を提供するコントロールですが、デザイナー自体がExcelライクな操作感で、直感的に編集が可能です。ちょっとやりすぎなくらい、素晴らしい使い勝手だと思います。
実際に設定後の動作は次のようになります。
魅力的な機能が簡単に実現できていることが見て取れるでしょう。
本稿ではSPREAD for WPFについて、あまり深く踏み込んで解説しませんので、興味のある方は次の記事もご覧ください。
さてユーザ操作性と生産性の側面を見た場合、選択の候補としてはOSSプロダクトもあるでしょう。今回利用するのはグリッドのみで、OSSでもSPREAD for WPFに並ぶほどの機能性をもった製品は私は把握していませんが、もう少し一般的なコントロールであれば、OSSプロダクトも機能面では視野に入ってきます。
ただ、エンタープライズ領域の受託開発を想定した場合、個人的にはユーザーインターフェースライブラリは商用製品に比重を置きたいと考えています。
というのは、商用製品は対象バージョンの保守期限などが明確に定義されていることが多く、開発対象の保守計画をコントロールしやすいという面があるためです。
ではユーザーインターフェース以外はOSSで問題ないのか？ となりますが、例えばDependency Injectionコンテナであれば、場合によって製品を変更したとしてもアプリケーション全体への影響は極小です。DapperやDapperの拡張ライブラリは十分に枯れていますし、仮に何らかのトラブルがあっても、自分自身で対処が可能なものが多いです。そもそも、これらの領域は対抗となる有償製品が無い、または少ないという根本的な理由もあります。
またエンタープライズ領域の受託開発では、開発メンバーや保守メンバーの継続的な維持が難しいという実情もあります。このため日本語のドキュメントや、日本語でのサポートが受けられるというのも大きな強みです。
ユーザーインターフェース以外のライブラリは、利用方法が限定的であるものが多いため、日本語の情報がある程度でそろっていることも多いですし、英語のドキュメントを読むにしても比較的容易でしょう。
逆に有償製品を採用する上での最大の難関は予算の確保です。
明らかに自作するよりも有償製品を購入することが安いとわかっていても、プロジェクトの予算が決定して走り出してからでは、有償製品を追加購入することは難しい現場が多いのではないでしょうか？
この課題は、顧客への見積提示前にアーキテクトが参画し、事前に予算を確保しておくことが最も確実な対処方法です。エンジニアが参画した時点で、アーキテクチャの大枠が決定済みで不自由な開発を強いられるといった話を稀に聞きますが、そういった意味でもアーキテクトは見積前の段階から参画することが重要だと、私は考えています。
話が少し発散してしまいました。
あらためて、SPREAD for WPFを選定した理由について振り返りたいと思います。
最も大きなポイントは次の二点です。
- 高いユーザ操作性を低コストで実現可能
- 高い技術的安定性
これに加えて、日本語のドキュメントが充実しており、サポートも日本語で受けることができる面も高く評価し、本システムではSPREAD for WPFを採用することとしました。
