ASP.NET MVCプロジェクトにWebサービスを追加すると、MVCの概念全体が壊れますか?
そのWebサービス(WCF)は、バックエンドと通信するためにMVCプロジェクトのモデルレイヤーに依存しています(したがって、MVCソリューションの一部である必要があるように見えます)。
これをコントローラーまたはモデルレイヤーに追加する必要がありますか?
ASP.NET MVCプロジェクトにWebサービスを追加すると、MVCの概念全体が壊れますか?
そのWebサービス(WCF)は、バックエンドと通信するためにMVCプロジェクトのモデルレイヤーに依存しています(したがって、MVCソリューションの一部である必要があるように見えます)。
これをコントローラーまたはモデルレイヤーに追加する必要がありますか?
モデルを独自のアセンブリに分割し、MVC アプリケーションと WCF アプリケーションから参照する必要があるようです。
WebServices MVC スタイルを実行したい場合は、MVC を使用して独自の REST アプリケーションを構築する必要があります。
MVCアプリケーションにWebサービスを追加する必要がある特定の理由はありますか?特に理由がない限り、RESTfulWebサービスと同じようにRESTfulな方法でコントローラーを使用する必要があります。
詳細については、Rob Conneryからのこの投稿を確認してください: ASP.Net MVC:RESTfulアーキテクチャの使用
モデルを独自のプロジェクトに分離しても、「MVC」パターンは崩れません。まず、パターンです。MVC パターンの意図は、データ、データ ハンドラー、およびプレゼンターと、それらの間のインターフェイス方法を明確に区別することです。それを行う最善の方法は、セブが提案した方法です。
Rob Conery がまとめた MVC Storefront が役立つかもしれません。ここでビデオを見てください:
そして、ブラウザで実際のコードを見て、彼がどのようにそれを行ったかをすぐに確認したい場合は、ここにアクセスしてください: MVC Storefront Codeplex Code Browser
モデルを独自のアセンブリに分離しても、MVC を使用しているかどうかに関係はないと思いますが、モデルはまだあります。どこにあるかは関係ありませんか?
私はこれをやってみました。
私のブログで私の結果を参照してください
ps: Web サービスは XML ダンプを返すだけなので、Web サービスがリポジトリのモデルであると考えている限り、これが MVC の概念を壊すとは思いません。
アプリケーションにWebサービスを追加しましたが、うまく機能します。モデルの代替インターフェースであるため、MVCに違反しているとは思いません。Webサービスにはビューがないため、MVCはWebサービスには適していません。
Web サービスとデータベースは 1 つのものと考えてください。この類推の下で、データベース ロジックを配置する場所に Web サービス インタラクションを配置することは理にかなっていると思います。