0

そのため、これまで、私が取り組んでいるWebサイトは、データアクセスとアプリケーションおよびビューコードを直接組み合わせた単一レイヤーのアーキテクチャに依存していました。私は最近、データアクセスサービスレイヤー（API）を実装することの利点をチームに確信させました。特に最近の水平スケーリング（ネイティブモバイルアプリケーションなど）の話では。

現在頭に浮かぶ実装は、クライアントがサービスを使用して要求するクラスにEntity Frameworkデータベースをマップするために 使用することです。 私は過去にこのアプローチを小規模で使用していましたが、現在はデータオブジェクトの大規模なコレクションの範囲であり、それぞれにクエリが実行される可能性のある多数の基準があり、APIの構造化方法を想像するのに問題があります。 Data ContractWCF

データクラスのリストの例：

  • 製品
  • 商人
  • ブランド
  • 分類法
  • クーポン
  • ユーザー
  • レビュー
  • 質問
  • 回答
  • 等

（うまくいけば、これらのオブジェクトが関連している方法は、私の主張をするのに十分明白です）

サービス要件

  • サービスは言語に依存しない必要があります（.net、php、java、Objective C）
  • パターンは、1つのAPIとして機能する複数の異なるデータソースを許可する必要があります（たとえば、ユーザーはMSSQLサーバーに保存され、MySQLのレビューシステムはXMLフィードから取得されます）
  • API側からオブジェクトキャッシングを実装できる必要があります

これらの各データオブジェクトは、基本的に、その列のいくつかに基づいてクエリ可能である必要があります（単一のオブジェクトまたはコレクションを返すため）。さまざまなシナリオごとに新しいAPIメソッドを作成することはできますが、これを行うにはもっと洗練された方法が必要だと思います。

リクエストの例：

  • IDで単一の製品を取得します。
  • 「作成日」、「価格」、または「パーセントオフ」の順に並べられた特定の販売者、ブランド、または分類法から製品のリストを取得します。
  • ユーザーから送信されたすべてのレビューを取得する
  • 製品のすべてのレビューを取得する
  • ..。

私の調査では、APIを作成するためのいくつかの標準的なアプローチを概説したこのMSDNの記事に出くわしました。それぞれの長所と短所、および上記で説明したモデルに最も適していると思われるアプローチを聞くことに興味があります。

4

1 に答える 1

1

基本的に、これを正確に行う多くのパターンがあります。UIレイヤー=>データアクセスレイヤー=>DALで使用されるコアレイヤーEF、COREのモデルとロジック。Coreは、他のレイヤーが使用するインターフェースとモデルを宣言します。

「リポジトリパターン」作業単位パターン「制御の反転オプションの追加」を読んでください。50USDをテーブルに置く準備ができている場合は、http：//Pluralsight.com にこれらの概念を説明する優れたビデオチュートリアルがいくつかあります。 。サンプルアプリなどもあります。私の見解では50USDが十分に使われています（1か月のサブスクリプション）。

特に、EFとエンタープライズアーキテクチャに関するJulieLermanによるpluralsightのビデオをお勧めします。そこにいくつかの非常に良いヒント。

私はそのようなパターンを使用します。そしてそれは非常にうまく機能します。

于 2012-12-19T01:41:51.240 に答える