Lightswitchアプリケーションフレームワークの周りに話題があるようです。いくつかの投稿/フォーラム/記事を読んだり、ビデオを聞いたりすると、いくつかの答えが得られましたが、他のいくつかの答えが出ました。
拡張性？ 機能をオーバーライドまたは拡張するためのフックはいくつかありますか？
モジュール性？MEF / Prismは統合できますか？実行時にロードできる動的モジュールの概念はありますか？
ローカライズ可能？異なる言語でのローカリゼーションに関する特別な機能はありますか？
バージョン管理可能ですか？同時バージョンが共存できるバージョンの概念はありますか？
抽象化？データソースへの接続を抽象化して置き換えることができますか？
妥当性？さまざまなコンポーネントユニットを自動化された方法でテストできますか？達成するのは簡単ですか、それとも難しいですか？
横断的/NFR？NFRコードをプラグインできるようにするためのフックはありますか？（ロギング、キャッシング、監査、セキュリティ）
これは、PAASアプリケーションを構築するための堅固なフレームワークですか？
私が行った評価に基づいて、2セントを差し上げます。
拡張性
もちろん、カスタムコントロールを追加することもできます。明らかに、公開された拡張性APIがあります。
モジュール性
いいえ。ライトスイッチはコードジェネレーターではなく、UIの実装を抽象化します。
ローカライズ可能
何も見えませんでしたが、段階的に発生すると思います。
バージョン管理可能ですか？
LightswitchプロジェクトをTFSすることもできますが、実行の観点からバージョン管理を行う場合は、新しいバージョンのアプリをサーバーにデプロイするのと同じくらい簡単です。クライアントは実行時に更新をチェックし、必要に応じて私が理解していることからインストールします。
抽象化
はい、非常に簡単に実行できるWCFRIAサービスレイヤーで抽象化すれば可能です。
妥当性
ビジネスルールはRIAサービスレイヤーで実装できるため、テストは簡単ですが、UIを介して駆動されるルールに大きく依存している場合は、別のUIベースのテストツールを使用する必要があります。
横断的/NFR
アプリのRIAサービス層をビジネスルールの中心的な場所にすることに重点を置き、UIをユーザーエクスペリエンスのみに集中させると、重複が少なくなります。Lightswitchは多くのソリューションにとって優れたクライアントだと思いますが、Lightswitchのコアパワーは、Lightswitchにまったく依存しないRIAサービスのクライアントとして使用することです。
少なくともいくつかの有用な洞察を提供したいと思います。
拡張性？組み込みのLSコントロールで必要な操作ができない場合は、ほぼすべてのSilverlightコントロール（サードパーティのコントロールを含む）を使用するか、独自のカスタムSilverlightコントロールを作成できます。LSコントロールにはいくつかの追加の「スマート」が組み込まれているため、LSコントロールを使用するよりもやるべきことが少しあります。そのため、画面にドロップしてバインドし、使用するだけです。フレームワークには、独自の「拡張機能」（シェル、コントロール、テーマなど）を作成できる拡張性ポイントも組み込まれています。
モジュール性？LSはすでにMEFを隠蔽して使用しているため、将来的にはさらに活用できる可能性があります。LSはコードを生成しますが、それ自体は外部消費用ではありません。ただし、MicrosoftのEricErhardtによる優れた記事があります。
これは、LSが構築するデータモデルを再利用する方法を示しています（Ericの場合、彼はそれを使用して、チャートコントロールに表示するためにデータを集約するRIAサービスを作成します）。
ローカライズ可能？現在、組み込みのローカリゼーション機能はないと思います。
バージョン管理可能ですか？Webベースのアプリの場合、データスキーマが変更されていない場合、個別のバージョンを公開できなかった理由はわかりませんが、デスクトップ（OOB）アプリはクリックワンスアプリであるため、そのテクノロジーによって管理されます。
抽象化？データソース用のRIAサービスを作成する場合は、実装の詳細を抽象化できます。
妥当性？残念ながら、V1は「テスト容易性」を念頭に置いて作成されていません。ビジネスロジックをSilverlightクラスライブラリ（クライアントで使用するため、またはサーバーで使用するための完全な.NETクラスライブラリ）に抽出する場合、そのロジックを単体テストできますが、LSアプリケーション自体で作成するコードは現時点では、実際には単体テストはできません。