リポジトリ パターンを Web サービスと統合するための最良の方法を確認できる人はいますか。DataAccess、Services、プレゼンテーション レイヤーの 3 つのプロジェクトがあります。
問題は、私のプレゼンテーション レイヤーにさまざまな問題があることです... ASP.NET MVC サイトがあり、WPF アプリケーションがあり、別のサイトを作成しようとしています + 外部の会社もリポジトリにアクセスする必要があります。
現在、各サイトへの参照としてサービス層を追加したところです...しかし、Web サービスを介してデータ アクセスを提供する通常の方法ではありませんか? (WCF) - この場合、サービス層が壊れますか? または、サービス層を Web サービスに変換する必要がありますか?
この速度の長所と短所を知っている人はいますか??
私はあなたのジレンマを理解していると思います。私の理解が正しければ、あなたのサービス層は純粋な捏造で構成されています。http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) .
上記の前提が正しければ、サービス レイヤーは WCF の導入によってまったく影響を受けないはずです。WCF は基本的に、相互運用性を提供する追加のプレゼンテーション レイヤーであり、UI プレゼンテーション レイヤーとビジネス ロジック レイヤーの間に位置します。したがって、WCF サービスはサービス層を呼び出し、必要に応じてリポジトリにアクセスできます。
WCF は高度な相互運用性を提供するため、優れた選択肢だと思います。ただし、これが最も柔軟であるため、異なるプログラミング言語と相互運用する場合は、basicHttp バインディングを使用します。速度は気にしないでください。WCF が原因で発生するボトルネックを軽減するためのソリューションは数多くあります。
頑張ってください。他に何かお手伝いできることがあればお知らせください。
まず最初に、すべての呼び出し元が同じリポジトリAPIを使用する必要があるわけではありません。これは特に外部の会社に当てはまります。
WCFはインターフェイスベースです。つまり、ロジックコードを再利用する必要がある場合は、アセンブリ共有を使用することで、DALではなくIoC / DIを使用して（ただし同じインターフェイスを使用して）WCFを挿入できます。これがあなたがしていることのように聞こえます。これは多くの場合に機能しますが、すべてではありません。基本的に、WebサービスベースのAPIは、最適化するために異なる設計が必要になることがよくあります。また、SOAの観点からは100％純粋ではありませんが、仕事をこなし、よりインテリジェントなドメインエンティティを可能にするため、イントラネット（etc）シナリオでは（IMO）完全に合理的です。
外部の呼び出し元は通常、（アセンブリ共有ではなく）wsdl / mexベースのAPIを使用しますが、何でも可能です...
サービス アセンブリに完全にアクセスできる場合は、サービス レイヤーをアプリケーションとアセンブリ共有する方が常に良いと思います。
私のアプリケーションは同様のことを行いますが、すべてサービス層にアクセスする必要があります-ビジネスロジックと情報を取得する...
この場合、HTTP プロトコルを使用して WCF Web サービスを提供したり、wcf で TCP を使用したりするよりも、サービス レイヤーでアセンブリ共有を使用することを常にお勧めします。
再度、感謝します
サービス/API アセンブリをクライアント アプリケーションと共有するかどうかは、かなり主観的なものです。あなたが完全な Microsoft ショップであり、アプリケーション スタック全体に .NET を使用している場合、API を共有することは、コードを再利用するための優れた方法であると言えます (出血しないように、API の設計方法に注意する必要があります)。クライアント アプリケーションを他のプラットフォームに移行する計画がない場合 (つまり、近い将来 .NET にとどまる予定の場合) は、共有しても問題ないと思います。サービス/API アセンブリ (その場合でも、マルチプラットフォーム クライアント環境では、サービス/API を .NET クライアントと共有することは引き続き許容されるはずです。)予算内」。アーキテクチャの理想を達成するために、多くの時間、お金、労力を費やすことができますが、それと実際のギャップはそれほど大きくないことがよくあります。API を共有せず、基本的に再作成して「正しい」SOA を維持し、コントラクトのみを消費するという選択は、実際には作業を増やし、この特定の時点での特定のプロジェクトにとって価値のないメンテナンスの手間を導入する可能性があります。あなたがすでに一般的に「サービス指向」であることを考えると、将来の時点で、クライアントでの契約のみの消費が提供できる利点が必要な場合は、すでにそこに行く準備ができています. しかし、あまりにも早くプッシュしすぎないでください。API を共有せず、基本的に再作成して「正しい」SOA を維持し、コントラクトのみを消費するという選択は、実際には作業を増やし、この特定の時点での特定のプロジェクトにとって価値のないメンテナンスの手間を導入する可能性があります。あなたがすでに一般的に「サービス指向」であることを考えると、将来の時点で、クライアントでの契約のみの消費が提供できる利点が必要な場合は、すでにそこに行く準備ができています. しかし、あまりにも早くプッシュしすぎないでください。API を共有せず、基本的に再作成して「正しい」SOA を維持し、コントラクトのみを消費するという選択は、実際には作業を増やし、この特定の時点での特定のプロジェクトにとって価値のないメンテナンスの手間を導入する可能性があります。あなたがすでに一般的に「サービス指向」であることを考えると、将来の時点で、クライアントでの契約のみの消費が提供できる利点が必要な場合は、すでにそこに行く準備ができています. しかし、あまりにも早くプッシュしすぎないでください。将来の時点で、クライアントでの契約のみの消費が提供できる利点が必要な場合は、すでにそこに行く準備ができています. しかし、あまりにも早くプッシュしすぎないでください。将来の時点で、クライアントでの契約のみの消費が提供できる利点が必要な場合は、すでにそこに行く準備ができています. しかし、あまりにも早くプッシュしすぎないでください。
あなたのニーズを考えると、これまでの投稿から収集できたことから、あなたのサービスも順調に進んでいると思います。リポジトリ (Evans、DDD 風) は間違いなくドメインの問題であり、そのため、プレゼンテーション レイヤーの観点からは特に気にする必要はありません。サービスは、ビジネス ロジックのホームであるドメインへのゲートウェイです。リポジトリは、データ ストアからのドメインの分離を実現するのに役立つサポート機能にすぎません (それらは実際には美化されたコレクションであり、率直に言って...動的で複雑なドメインでは少し面倒な場合があります。単純なデータ マッパー、 (Fowler、PofEAA) は、多くの場合、長期的にははるかに扱いやすく、複雑さが軽減され、データ取得ロジックに関するより適応性の高い動作をドメイン サービスに集中させることができます。) REST サービスへの AJAX 呼び出しを頻繁に使用することは別として、ドメインで適切なサービス/API を公開する場合、クライアントが心配する必要があるのはそれだけです。残りのすべてのビジネス ロジックをドメインの範囲内に完全にまとめ、クライアントを可能な限り軽量に保ち、「リポジトリ」や「データ マッパー」などの概念から抽象化します。
私の経験では、クライアントとドメインの境界を越えて共有する必要がある唯一のサービスまたは API 以外の概念はコンテキストです...そして、サービス指向アプリケーションでその境界を越えることは非常に難しいことで知られています。