MVCフレームワークの使用を開始しましたが、ビジネスロジックやコントローラ、モデルのどこに書き込むのが混乱しますか？MVCモデルとコントローラここで何を書きますか
プロジェクトでは、DALとしてWCFレイヤーを使用します。
人々はモデル&コントローラで異なる意見を持ち、 'M'または 'C'のどちらかにビジネスロジックを書くのとは異なると考えます。
ベストプラクティスは何ですか？
モデルでWCF（DAL）サービスにアクセスし、すべてのビジネスロジックやフィルタリングを適用してから、コントローラがモデルからデータにアクセスすると思います。
これらは私のルールです：
コントローラ
主にページフロー。次に表示されるビューを決定します。
は、私はそれらの2を持っているサービス（すなわちproductService.GetProduct（Model.ProductID））
モデル
へのアクセス権を持っています。
POCO-クラス - すべての層で使用される（BLL、DAL）
のViewModel - stronly型付けされたビューのビューとコントローラが使用します。
ビュー
うまくいけば、主に簡単なHTML
私は、プロジェクトで働いて、人々のさまざまな種類を持つことが可能であること、のようにレイアウトを持つようにしてみてください。フロントエンドの男とバックエンド男。 バックエンドのユーザーはサービスとリポジトリを行います。
フロントエンドの男はコントローラとビューを行います。彼はまた、アヤックスをします。
ほとんどの人はビジネスロジックをモデルに保持していますが、これはベストプラクティスと考えられます。 xValを書いたSteve Sandersonはこのメソッドを支持しています。
前述のように、モデルの役割はビジネスの働きを表現するためのものであるため、検証モデルはドメインモデルに入れなければなりません。これは、UIコーダーがそれらを記憶しているかどうかにかかわらず、ルールが一貫して強制されるようにします。
あなたが議論している問題について語っているxValについての彼の投稿を見てください。
ビジネスロジックとアプリケーションフローロジックを分離してください。ほとんどの人は、それらを一緒に混ぜ合わせる傾向があります.-ビジネスロジック -
モデルがデータアクセスロジック（あなたのケースではwcfサービス）から構築されているとは思わないでください。私はDomain Driven Designをチェックアウトすることをお勧めします、それはMVCとうまくいく。コントローラにはビジネスロジックを含めるべきではありません。コントローラーの動作方法は20行以下にする必要があります。しかし、それはちょうど私の意見です（無数の情報源から構成されています）。