討論 : MicrosoftのRIA Serviceのコード生成ツールと正しい設計原則

作者 Abel Avram , 翻訳者 徳武 聡 投稿日 2010年2月3日

セクション

デベロップメント

トピック

RIA ,

.NET

タグ

Visual Studio ,

Services ,

Debate

原文(投稿日：2010/01/28)へのリンク

MicrosoftのRIA Serviceのコード生成ツールは悪い設計原則を広めていると考えている開発者がいる一方で、このツールは適切に使えば便利だと考えている人もいる。

とても単純なアプリケーションなら特に設計のことを考えなくても素早く構築できる。ビジネスロジックがほとんどないのだから、プレゼンテーション層から直接データベースへアクセスしてしまってもいいだろう。しかし、ビジネスロジックがどんどん追加されてアプリケーションが複雑に成長したらどうなるだろう。そのままプレゼンテーション層から直接データベースへアクセスする実装でいいのだろうか。良識ある設計原則の答えは“No”だ。こういう方法はふたつの層に強い結びつきを生み、一方の層へのちょっとした変更がもうひとつの層へ伝播してしまう。

Microsoftが一見すると開発者の生活を楽にするコード生成ツールを提供していることはよく知られている。しかし、これらのツールは大きなプロジェクトでは使い物にならないのも周知のことだ。また、これらのツールは新人の開発者に悪い手法を教えてしまうと危惧する人もいる。RIA Serviceのツールも例外ではない。

Visual StudioのRIA Serviceのクラスライブラリのプロジェクトはデータアクセスに必要なサービスを生成してくれる。これは素晴らしいアイデアのように思えるが、生成された単純なコードを使おうとすると、Silverlightのようなクライアントアプリケーションから直接データベースにアクセスしても何の問題もないように思えてしまう。つまり、クライアントアプリケーションとデータベースの結合度を下げるかわりに、データベースへのインターフェイスのように振る舞うサービスとクライアントの間の結合度が高まってしまう。.NET開発者でありNHibernateやAgathaプロジェクトにもコミットしているDavy Brion氏はDBへアクセスするサービスをVSを使って生成している。曰く、

確かにこの方法は簡単です。データベースのAlbumテーブルにCRUD処理が行えるサービスが手に入ります。お望みなら、ユーザがアルバムを一覧して、編集したり削除したり、新しいアルバムを追加したりするSilverlightの画面を作成するのもいいでしょう。‘サービス層’を変更する必要もありません。問題なのはその通りにやってしまう開発者が多すぎることです。  なんでMicrosoftのツールが生成するコードを逐一疑わなければならないでしょう。こういうコードを生成するということは、こういうコードを使ってほしいと思っている人がどこかにいるってことだと思うのですが。え、違うって？じゃ、なんでこんなコードが吐き出されるんでしょう。

しかし、氏はVSによって生成される基本的なサービスはそれほど素晴らしいものではないと考えている。

Microsoft主催イベントのデモで、このような生成ツールが喝采を浴びているのはきっと間違いないんでしょうが、それ以外でなにかいいことをもたらしてくれるんでしょうか。サービスを開発するのにこの方法が本当に望ましいのでしょうか。リモートクライアントに対してあるがままのデータベースの姿をさらすように実装させたいのか。私の考えはいたって単純で、こんなふうにコードを生成するのは不適切だと思います。多くの開発者が上述のようにクライアントコードからそのまま使ってしまうからです。もちろん、彼らのほとんどは認証機構も一緒に実装しますが、実際のビジネスロジックを実装する人がほとんどいないのは間違いありません。それはなぜか。生成されたコードから得られるのは、サービスが単なるCRUD処理の入り口になっているという実装だからです。こんな状態で、サービスに一体どんなビジネスロジックが必要なのでしょう。サービスにビジネスロジックを実装しようとは思えない作りになってしまうので、プレゼンテーションレイヤに実装してしまうのです。

Jeffrey Palermo氏はBrion氏に賛成して、Microsoftがなぜこんなツールを作ったのか自分なりの考えをコメント欄で表明している。

Microsoftは使いやすいツールを作ってきた歴史があります。私はあなたの設計原則にも賛成ですし、メンテンンスしやすさを考慮して革新的な設計を避けるのも賛成です。Microsoftのプラットフォームは導入しやすいので広く受け入れられていますし、導入するのは決して悪い意思決定ではありません。そして、顧客の理解が深まれば、既定で結合度が強まってしまうような方法でアプリケーションを作るよりもより良い設計方法を採用しようとします。しかし、そう考えるようになる前はなんらかのソフトウエアを使うこともあるでしょう。そのとき、選択肢がほかにないのなら、Microsoftのツールが受け入れられる余地があると思います。

Eric Hauser氏はBrion氏の記事に対して、WCF Data Serviceはドメインオブジェクトを介したサービスを自動生成してくれること、したがってデータベースを直接扱うサービスは必要ないことをコメントしている。

Data Serviceにはリフレクションに基づいたプロバイダもあり、(データベースではなく)ドメインモデルをサービスとして公開することもできます。私はいま(バージョン1.5を使って)カスタムのプロバイダを実装しています。このプロバイダはクライアント側に意識させずにメタデータをロードしてクライアント側のカスタマイズに応じたウェブサービスを生成します。この方法ならモデルをはっきりと制限できます。

WCF RIA Serviceは正しい設計原則を適用することを妨げない、とコメントしているのはBruce氏だ。

多くの開発者はWCF RIA Serviceを賢く使っていないのではないでしょうか。しかし、WCF RIA Serviceを賢く使える開発者はたくさんいると思います。

WCF RIA Serviceがいいのは、プレゼンテーションレイヤから分離されている、ビジネスロジックの記述場所(ドメインのサービスクラス)を提供してくれることです。これを使えば、ビジネスインターフェイスやロジックを構築するのにとても柔軟に対応できます。

なので、 WCF RIA Serviceを使っているからといって設計原則を生産的に適用できないということはないと思います。

あなたの意見はどうだろう。MicrosoftのRIAコード生成ツールは便利だろうか。それとも開発者に悪い設計を刷り込んでしまうか。うまく使いこなす方法はあるだろうか。

• 次へ >