私は LightSwitch で簡単に遊んだだけで、内部アプリケーションの優れたフレームワークになる可能性があるように見えますが、簡単に作成できるアプリケーションを約束した他の多くのツールのようになるのではないかと心配しています。最も基本的なアプリケーションであったため、従来の言語/フレームワーク (.NET など) で行うよりもはるかに困難になりました。
では、人々はどこで立ち往生しているのでしょうか。複雑さが生じたときにそれに対処するのはどれくらい難しいですか? どの程度拡張可能ですか？今見る価値はありますか、それとも次のベータ版まで待つ方がよいでしょうか?
まだ壁にぶつかったことはありませんが、テーマに基づくカスタマイズ フックは本当に苦痛です。また、LightSwitch プロジェクトに追加するコードは単体テストできないことに注意してください。
この性質のすべてのシステムと同様に、デフォルトの動作をカスタマイズする必要がある場合、問題が発生します。
そのような例の 1 つは、この記事http://ayende.com/Blog/archive/2010/08/25/analyzing-lightswitch-dataで説明されているように、親 -> 子関係のクエリが実行される方法を変更しようとする場合です。-access-behavior.aspx
LightSwitch V1 は当初、非開発者、「部門」アプリなどを対象としていますが、必要に応じて、少し高度な状況のコードにドロップダウンできる多くのポイントを提供しています。ほとんどの SilverLight コントロールを「カスタム コントロール」として使用することも、独自のカスタム SilverLight コントロールを作成することもできます。さらに深くする必要がある場合は、カスタムの「拡張機能」を作成することもできます。
多くのプロの開発者 (私自身を含む) は、LS が非常に便利なツールであることを認識しています。開発者のこの関心が、将来のバージョンで LS の方向性を推進するのに役立つことを願っています。現在のバージョンである B2 には Go-Live ライセンスがあり、現在かなり大きなアプリを構築しているユーザーが多数います。
ベータ 2 と RTM の間に追加された新機能はありませんでしたが (いくつかの機能は微調整されました)、チームが参加して V2 に含めるための多くのフィードバックがありました。
かなり活発な MSDN フォーラムがあり、質問をしたり、ユーザー、開発者、および LS チーム メンバーから助けを得たりすることができます。
http://social.msdn.microsoft.com/Forums/en/lightswitchgeneral/threads
私が経験した最大の問題は、生成される SQL クエリによるパフォーマンスの制限です。大規模なテーブル (> 1000 万レコード) ではパフォーマンスは良くありませんが、Lightswitch の範囲はそのような大規模なシステムではなく、データセットが少ないと予想される部門別ソリューションであると言えます。
ただし、Lightswitch の実際の制限のほとんどは、Lightswitch の問題ではなく、一般的な Silverlight の問題です。たとえば、限定された WCF サポートは、エンタープライズ アプリの問題です。