ASP.NET MVC-MVCのM、V、Cはドメインエンティティを明示的に認識する必要がありますか?


8

この質問はかなり主観的なようですので、ここに投稿します。

あなたはASP.NET MVCを使用してStackOverflowの独自のバージョンを書いているとしましょう、そうのようなクラスがありQuestionAnswerUser、などあなたがしている怠惰な、あなたはエンティティフレームワークを使用することにしましたのでは。したがって、上記のすべてのクラスにはナビゲーションプロパティがあります。QuestionそのAnswersをAnswer知っている、User投稿者を知っているなどです。

Martin Fowlerの本をたくさん読んだことがあるので、すべてのビジネスロジックを実装するためのサービスレイヤーが必ずあるはずです。ASP.NET MVCは、UIおよびアプリケーションロジック関連の機能にのみ使用します。

2つの質問があります。

  1. あなたは直接のオブジェクト公開しますQuestionAnswerコントローラーにして他の人を?
  2. ビューに対しても同じことをしますか?

私は基本的に自分のアプリケーションにREST APIを提供するつもりもありませんし、「ちょっと、MY VIEWはそれが何であるQuestionかを知っているので、それが悪いかどうかわかりません。気に入らない!」

Questionクラスに次のようなフィールドがTimePostedあり、PostNewQuestionビューをそのクラスにバインドする場合に特に興味があります。そのフィールドをページ上のどのコントロールにもバインドしない場合は、投稿されないのでnull、コントローラー側でオブジェクトを取得したときにそのフィールドを設定します。それは大丈夫ですか、それとも悪い考えですか?私が考えている2つの反対のアプローチは、「どこでもDTO / ViewModelを使用すること」と「wtf、クラスが少ないほど常に良いことです!」です。

正しいアプローチは何だと思いますか?(私は直接的な答えがないことを知っているので、問題は「DTO / ViewModels /その他のアプリのアーキテクチャに適しているかどうかを判断するために何を検討すべきか」です。)

また、Stackoverflowの非常に簡略化されたクローンを検討していることにも注意してください。

  1. これはWebのみのプロジェクトです(REST APIなどは公開しません)。
  2. ユーザー、質問、回答、タグ、検索機能があります(優れたビジネスロジックはありません)
  3. 1日あたり100人ほどのアクティブユーザーがいます(特別なパフォーマンス要件はありません)
  4. 新しいメンバーが開発チームに加わった場合でも、コードは読みやすく、驚きや特別な関心のある場所があってはなりません。

最初の3つのポイントが変更された場合の考えを表明することもできます-「顧客は、10000人の同時ユーザーを許可するために私たちのサービスを望んでいる」または「すべてのユーザーが15分に1回だけ投稿できるようにする必要がある」など。

ありがとう!

回答:


3

私はMVCをあまり使用していませんが、MVVMを使用して多くの作業をしてきました。

QuestionAnswer、およびUserすべてのデータ・オブジェクトです。彼らがお互いを知ることは問題ありませんが、ビュー、コントローラ、ビューモデルなど、データオブジェクトレイヤの外側にあるものは何も認識してはなりません。

理想的な世界では、ビューはモデルのみを参照します。彼らはコントローラを知っているかもしれませんが、それを直接参照する必要はありません。ViewModelは他のモデルのみを認識します。コントローラはモデルとビューモデルについて知っています。ビューにViewModelsまたはModelsを提供しますが、ビューはまったく気にしません。

したがって、オブジェクトは次のようになります。

  • Mのモデルとのviewmodels:odelsは2種類があります。

    • モデルは単純にデータを保持するために存在する単純なデータオブジェクトであり、一般にデータベースデータを反映しています。彼らはデータベースにアクセスしたり、彼らとは無関係のあらゆる種類のビジネスロジックを含んでいません。
    • ViewModelは、ビューが必要とするデータを含むデータオブジェクトであり、必ずしもデータベースが必要とするものではありません。モデルにはViewModelを含めることはできませんが、モデルを含めることができます。
  • Cの ontrollersは、ビジネスロジックが含まれています。データアクセス呼び出しを制御し、ビューに渡すモデル/ビューモデルを作成し、権限などの高度なビジネスロジックを制御します。基本的に、コードレイヤー全体を制御します。

  • Vの iewsだけでユーザーにユーザーフレンドリーなインターフェイスを与えるために使用されています。これらはViewModelまたはModelのいずれかを受け入れ、ユーザーに見栄えのよい方法で表示します。


MVVMはWebプロジェクトでは実際には意味がありません...
yannis

1
@YannisRizosこれはMVVMではなく、MVCです。MVCにもViewModelがありますが、それらはモデルレイヤーの一部です。これらは、本質的にはビューのモデルであり、ビジネスロジックを含む独自のレイヤーではありません(MVVMにあるものです)。WPF / Silverlightを使用しているのでない限り、実際にはMVVMの使用はお勧めしません。
レイチェル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.