Microsoftツールを使用しているデータ入力の集中的なイントラネットアプリケーション

Question

実際に問題が発生する前に、アプリケーションでは、現在処理中のアプリケーションは状態フローの単一モデルアプリケーションです。たとえば、異なるドメインモデルアプリケーションの状態。すべての状態で読み取り/書き込み/非表示の状態になりますが、ビジネスロジックを実行するために各状態ですべてのフィールドが必要です

このアプリケーションをMicrosoft TFS Web Accessとみなしたい場合は、私は今、私の自己:(

アプリケーションは現在（... grrrが聞かないでください）MS情報のパス形式で書かれているし、我々は病気とそれを維持オフに疲れている。

問題を気の毒に感じています...

現在InfoPathフォームにあります。異なる状態では、フィールドを読み込み専用、書き換え可能、または非表示にするために異なる「ビュー」を使用しています。すべての単一のビューを更新する）

私のチームメンバー全員がASP.NET MVCを推奨しています& JQueryの書き換え用私は個人的にMVCが現在経験しているのと同じ問題を作成すると思います（フィールドを読み込み専用、書き換え可能、または異なる状態で表示不可にする多くのビュー）

私たちは厳選した数を持っています。私たちはすでに銀色のライト、WPFとwindows Appsを除外しており、Webフォームを選択することは非常にありえないでしょう。

MVCはこのAPPの正しいフレームワークではないと私は思っています???

MVCが正しいフレームワークでない場合は、残りの選択肢はありますか？

Answer 1

それどころか、MVCは 異なる状態

ための書き換え可能か、目に見えない、タスクおよび読み取り専用フィールド を作るための異なるビューの

多くの問題のために非常に適してできています1つのビューと異なるテンプレートでかなり簡単に解決できます。

この問題は、実際に使用するUIフレームワークには関係しません.WebFormsやGrailsを使用するだけで解決するような問題ではありません。

ほとんどの開発者がMVCに満足しているのであれば、MVCに満足しています。 MVCはインターフェイスをロジックから分離するのに役立つ優れたツールであり、表示/エディタテンプレートが役立つはずです。

Answer 2

私は何十年もの間（10年以上）データ入力集中型（1日あたり何百万もの）アプリケーションを開発してきましたが、私はウェブアプリケーションがそれに適していないと言うことができます。私の推奨はsilverligth ASP.NET MVCは確かにあなたのアプリケーションのために動作しますがまたは一部のWindowsアプリ

今、あなたのアプリケーションとバックエンドの間の通信は間違いなくウェブをベースられるの形が、アプリ自体は良いアイデア

Answer 3

ないが、 ASP.NET Dynamic Dataをご覧ください。あなたの説明から、それはあなたのプロジェクト（過度に複雑なビジネスロジックなしで、主にデータ入力向けのアプリケーション）に適しているように思えます。