3

システム アーキテクチャに関するサポートを探しています。概要を説明しましょう:

一連の wcf サービスを介してアクセスされる SQL サーバーと Oracle データベースがあります。

これらの wcf サービス エンドポイントは、多数の Web アプリケーションによって使用されます。

すべてのアプリケーションは .net c# 4.0 で記述されています。

現在、モバイル アプリ (iPhone アプリ、Android アプリ) がデータベースによって提供されるデータにアクセスする必要があります。

最初の質問は、モバイル アプリにデータを提供するのに最適な媒体は何ですか? オプションには、モバイルアプリがアクセスできる WebApi または MVC コントローラーを公開する、配置されている wcf サービスまたはラッパープロジェクト (既存の wcf サービスを呼び出す) を介したものが含まれると思います。モバイル アプリケーションの使用に関する最適なアプローチに関する提案。モバイル アプリへの小さなペイロードの要件と、承認されていないモバイル アプリケーションがサービス/ラッパー プロジェクトにアクセスするのを防ぐためのセキュリティ対策も必要になることを念頭に置いてください。

次の質問は、WCF サービスのバージョン管理に関するものです。潜在的なラッパー プロジェクトに影響を与えることなく、wcf サービスをシームレスに更新できるようにしたいと考えています。サードパーティのモバイル アプリケーションはリリース サイクルが異なるため、複数のバージョンをサポートする必要があります。これには、アプリケーションの複数のバージョンの展開が含まれる可能性があると思いますが、そのような慣行は通常どのように処理されるのでしょうか?

すべてのアプリケーションは、IIS 7.0 の Windows サーバーに展開されます。

4

4 に答える 4

2

うーん...他の回答を聞くことに非常に興味がありますが、これはあなたの質問に対する私の見解です.

まず第一に、ビジネス ロジックを WCF サービスから分離する必要があると思います (まだ行っていない場合)。これにより、WCF サービスと並行して ASP.NET Web Api サービスをセットアップできます。MVC または Web Api を WCF に呼び出す代わりに、代わりに並べて使用できます。

最新のほうが相互運用性が高いため、WCF と Web Api の両方を使用するという考えの方が好きですが、WCF サービスで Json エンドポイントを作成することもできます。すべてのロジックをサービスから切り離すと、すべてのビジネス ロジックを共有することになり、かなり単純になります。

モバイルの iPhone および Android アプリの場合、おそらく Web Api サービスを使用する方が簡単です。サービス Api の複数のバージョンを維持する経験はあまりありませんが、Web API サービスにモバイル アプリを接続している場合は、API バージョンごとに複数のフォルダーを作成することでバージョンを管理できます。これにより、ビジネスロジックの重複が発生します...

私が言ったように、私は他の意見に非常に興味があります。

于 2012-05-10T22:06:11.933 に答える
1

モバイルサポートが必要な場合は、WCFを避けてWebAPIを使用することをお勧めします。その理由は、すべてのネイティブモバイルプラットフォームがXMLを使用でき、WCFでは基本的なHTTPバインディングを使用して古いスタイルのWebサービスをシミュレートできますが、Web APIは、これらのプラットフォームのブラウザーでも使用できるHTTPを介した無駄のない平均的な通信を提供します。ネイティブコードだけではありません。

モバイルで相互運用性がある場合は、WebAPIを使用することを躊躇しません。

特定の条件でのみWCFを使用します。

于 2012-05-10T22:40:05.567 に答える
1

疑わしい場合は、抽象化を挿入してください。すでにドメイン サービスとして構築されているサービスを想像してみてください。これらのサービスは、モデル (DTO) と更新 (API) を使用して、さまざまなニーズを持つ複数のクライアントにサービスを提供します。簡単にバージョン管理できるように実装し、ネットワーク上のコンテンツを削減する柔軟性を持たせるには、サポートする画面のレイヤーを導入します。

ドメイン サービスにのみ依存し、DTO をモバイル消費可能チャンクに変換する方法を持つ「モバイル サービス」を構築することをお勧めします。このレイヤーは、ASP.NET WebAPI 内に配置することも、vert.x または node.js の外部に配置することもできるため、必要に応じて機能を追加できます。最終的に必要なのは、ドメインと消費者の間のサービス コントラクトであり、それらの間にレイヤーを導入することで、長期的には莫大なコストをかけずにいずれかのエンドを置き換えることができます。また、スタック全体に手を加えなくても、必要に応じて API をバージョン管理できます。

もちろん、到達する論理エンドポイントを決定できるように、クライアント デバイスがサービスに必要な機能を事前に通知する方法を検討する必要があります。これにより、クライアントとドメイン間のバージョン ネゴシエーションの方法を開くことができます。

彼らがモバイル アプリをどのように構築したかについては、LinkedIn インフラストラクチャをチェックすることをお勧めします (そうです、彼らは ASP.NET を使用していませんが、アーキテクチャ パターンはまだ健全です)。

私の2c。

于 2012-05-11T12:50:05.503 に答える
1

Dante が言ったように、JSON を自分のデータ形式として間違いなく検討します。また、提案されているように n 層に分割します。

認証に関しては...

サードパーティのアプリはいくつありますか? あなたがたくさん持っているようには聞こえませんが、そうであれば（そして彼らは本当にサードパーティであり、つまりあなたによって管理されていません）、これに対するOAUTHソリューションを検討することをお勧めします.

あなたがほんの一握りしか持っておらず、あなたがコントロールしているなら、それはやり過ぎのIMOです。代わりに、各アプリが知っている単純な秘密鍵を持っているだけです。各呼び出しはキーを渡し、サービスはこれをチェックします。明らかに、すべての転送は SSL を介して行う必要があるため、キーやデータが何であるかを盗聴することはできません。

キーをチェックするという点では、アスペクトまたはカスタム属性を利用して、各関数でボイラープレートを作成する必要がなくなります。

于 2012-05-10T22:36:10.533 に答える