私は .Net RIA Services を初めて使用しますが、その本質は、Microsoft が通常気にかけている RAD をターゲットにすることだと思います。しかし、それはプレゼンテーションとアプリケーション/ビジネス ロジックとの間の結合をさらに導入しませんか? この新しいテクノロジは、OOAD のベスト プラクティスや、SOLID、GRASP、デザイン パターンなどの概念に関心を持つ開発者の増加にどのように役立ちますか? または、両方の目標を達成する方法はありますか?!
3 に答える
このような技術の作成者が、設計原理そのものへの関心を高めようとしているとは思えません。私たちが期待できる最善のことは、このようなフレームワークがベスト プラクティスに準拠した開発につながる可能性があることです。
プレゼンテーションとビジネス ロジックの結合に関する質問、および RIA がそれを増加させる傾向があるかどうかは興味深いものです。
結合を非常に慎重に定義する必要があります。ビジネス ロジックが変更された場合、プレゼンテーション ロジックのどの部分を変更する必要がありますか? プレゼンテーションの変更には、ビジネス ロジックの変更が必要です。
ビジネスのセマンティクスが変化した場合、RIA であろうとなかろうと、プレゼンテーション層をある程度変更する必要があります。したがって、ある種のカップリングは避けられません。ただし、適切に設計されたビジネス ロジックは多くの異なるプレゼンテーションをサポートする傾向がありますが、洗練された RIA アプリはビジネス ロジックにより多くの要件を課す傾向があると私は考えています。
したがって、.Net RIA は、私たちが望むエンド ユーザー エクスペリエンスを提供するために必要なことを行っていると思います。不要な結合を強制するとは思わない。過度の結合が生じていると思われる特定の例はありますか?
これは、開発者がビジネス層とプレゼンテーション層の間で何を共有するかに大きく関係しています。RIA Services を使用すると、プレゼンテーション レイヤーが Entity Framework クラスにアクセスできるようになりますが、これは明らかに結合につながります。
カップリングの問題を抱えている開発者 (全員がそうであるべきです) にとって、ビジネス層とプレゼンテーション層の間の通信モデルを定義することも簡単です。RIA サービスのサーバー側 (これは単なる Web サービスであるため、ビジネス層の一部と見なします) は、ビジネス オブジェクトからモデルを構築する方法を認識しています。Silverlight は、モデルを使用して提示する方法を知っているだけで済みます。それは私には結合していないようです。
私はここ数日間、同様の考えについてくよくよ考えてきました......これにより、開発者が分離アプローチを維持できるかどうかは完全にはわかりません...これを証明または反証する例でも素晴らしいでしょう!