1

私はMVC4アプリを作成しています。最初にEF5モデルを使用し、それをかなりシンプルに保ちました。これは巨大なアプリケーションにはなりません。一度に4〜5人しか参加できず、アプリケーションの任意の部分にアクセスできるようになる前にすべてのユーザーが認証されます。これは非常に単純な注文です。コーディネーターは注文を確認します。 -ディスパッチャは、注文の種類のアプリケーションを実行します。

基本的に私の質問は、アプリケーションのサイズとスコープが非常に小さい場合、リポジトリとViewModelについて心配する必要があるかどうかです。ドメインエンティティに強く型付けされているビューは、そのエンティティ内のすべてのプロパティを使用しています。私はコントローラーでTryOrUpdateModelを使用しており、これが多くの問題を引き起こす可能性があると言っていることをいくつか読んでいますが、それらの問題が何であるかについての情報は多くありません。非常に単純なアプリに、信じられないほど複雑なパターンを使用したくありません。

うまくいけば、私は十分な詳細を提供しました。誰かが私のコードを見たいと思ったら、私はここで本当に障害になっています、そしてコミュニティからのアドバイスを本当に使うことができます。本当にありがとう！

4

3 に答える 3

1

私の経験では、ソフトウェア ソリューションの要件は、初期の要件セットをはるかに超えて時間の経過とともに進化する傾向があります。

アーキテクチャのベスト プラクティスに従うことで、ソリューションの存続期間全体にわたって、ソリューションへの変更にはるかにうまく対応できるようになります。

リポジトリ パターンと ViewModel はどちらも強力であり、実装がそれほど難しくなく、時間もかかりません。小さなプロジェクトでも使用することをお勧めします。

于 2013-01-28T18:32:00.427 に答える
1

はい、引き続きリポジトリとビュー モデルを使用します。これらのツールはどちらも、コードをあちこちではなく 1 か所に配置できるため、時間を節約できます。おそらく、コピー ペースト エラーも回避できます。

さらに、これらのツールを配置することで、将来的にシステムへの拡張を容易にすることができ、可読性の低いすべてのコードを流し込む必要がなくなります。

懸念事項を分離すると、全体的なコードが少なくなり、システムがより効率的になり、コントローラー/コード セクションが小さくなります。ビュー モデルとリポジトリは、実装するのにあまり邪魔になりません。コントローラーファクトリーや依存性注入を実装しようとしているわけではありません。

于 2013-01-28T18:32:54.627 に答える
1

ビューモデル: はい

EF エンティティをビューに直接渡す場合にのみ、悪い点が見られます。

  • 過剰投稿や大量割り当てを防ぐために、ホワイトリストまたはブラックリストを手動で作成する必要があります
  • ビューから余分なデータを誤って遅延読み込みすることが非常に簡単になり、その結果、一部の N+1 問題が発生します。
  • 私の個人的な意見では、モデルはビューに表示される情報によく似ている必要があり、ほとんどの場合 (基本的な CRUD のものを除く)、ビューには複数のエンティティからの情報が含まれます。

リポジトリ: いいえ

Entity Framework DbContext は、既にリポジトリ パターンと作業単位パターンの実装です。すべてをテスト可能にしたい場合は、別のデータベースに対してテストするだけです。疎結合にしたい場合は、リポジトリを使用せずに EF でそれを行う方法があります。正直なところ、カスタム リポジトリの人気がよくわかりません。

于 2013-01-28T18:39:21.927 に答える