誤った情報に聞こえるリスクがありますが、これは基本的にRADやアプリケーションの高速スケッチに役立つと信じています。
CRUDアプリケーションに必要なほとんどすべてのものを足場にするという意味で、Ruby風のように感じます。私たちにとってより簡単な作業ですよね。そしてほとんどの人は賢明ではありません。
私は職場でかなりグリーンで、開発者として実際の仕事（キュービクルと無料のコーヒー）で働き始めたばかりなので、少しグリーンな意見かもしれませんが、もっと年配の人からのコメントが欲しいです。
これはMVC2（基本的な足場）とMicrosoft Lightswitch（ウィザード主導の開発）の間のどこかにありますか？参加する価値はありますか？
個人的には、管理ページに動的データを使用するのが好きです。これらのページは、実際には誰も見ることはできませんが、一部の管理ユーザーが使用できるようにする必要があります。以前は、開発チームが一緒に作成するのにかなりの労力を要していましたが、Dynamic Data を使用すると、ほとんど箱から出してすぐに使用できます。
MVC 2 のアプリケーションであるが、同じ UI プロジェクトに統合された動的データを管理者側に使用するTailspin travelをご覧になることをお勧めします。
最初は懐疑的でしたが、今では「標準の」ASP.NET サイトとほぼ同じくらい動的データを使用しています。箱から出してすぐに使用できるのはかなり一般的なものですが、カスタマイズ可能で、標準の ASP.NET ページを含めることができます。
最初は、「標準」アプリからのデータへの「バックドア」が必要なときに、別の管理サイトとして使用していました。しかし、最近の私のアプローチは、もう少し計画を立てて、動的データ メカニズムを介してユーザーにアクセスさせたいテーブルと、より細かく制御したいデータを決定することでした。必要なテーブルのみをスキャフォールディングできます。これは、エンド ユーザーが追加/削除できるようにする「ルックアップ」テーブルに適しています。例として、顧客がサインアップして電子メールでクーポンを受け取ることができる電子メール クーポン プログラムがあります。彼らはクーポンのカテゴリを選択できます - 温かい食べ物、飲み物、ガス、農産物などです。クーポン プログラム全体の管理者は、カテゴリを追加および削除できる必要があり、動的データはこの種のものに最適です。
動的データは、データの検証 (セキュリティと使いやすさに大きなプラス) を処理し、関係をマッピング (大幅な時間の節約) し、「正しく実行」します。ビジネス環境では、セキュリティと生産性は 2 つの非常に現実的な懸念事項であり、ほとんどの開発者はうまく処理できませんが、動的データは基本をうまく処理しているようです。
そうですね、それだけの価値があると思います。それは非常に強力で、あなたのツールボックスに入れておくべき優れたツールですが、時間と練習が必要なスキルを使って使用する必要があります. また、ツールボックスの唯一のツールであってはなりません。
私が聞いた動的データの最良の使用法の 1 つは、サイトのDjango のような管理セクションをすばやく構築することでした。ユーザー向けではないため、「完璧」である必要はありませんが、すぐに簡単に使用できるようになります。
私はそれについてほとんど知りませんが、私が考えるようなものではないようです。私がアプリケーションで作業するときはいつでも、階層化/再利用性などのいくつかの基本的なアーキテクチャのガイドラインに従う傾向があります。通常、私はこのようなショートカットツール/フレームワークから離れる傾向があります。.NETの世界で利用できる「きちんとした」ツールはたくさんあり、おそらく特定の中小企業/内部アプリスペースに配置されていますが、適切に設計されたアプリケーションには適していません。たとえば、GridViewに直接バインドできるデータソースコントロールにSQLを埋め込むなどです。