0

私の会社は、アプリケーションがファイルを保存するための巨大なストレージを購入しました。今後、当社が別のストレージ プロバイダーを選択する可能性は常にあります。そのため、REST サービスを使用してストレージに直接アクセスする代わりに、その上にラッパーを設計して、必要に応じて基になるストレージをあまり変更せずに変更できるようにしたいと考えています。

これから作成するサービス (REST) は、ストレージ サーバーとは別のサーバーで動作します。これはより良いアプローチですか?クライアントがサービスを使用してファイルをアップロードすると、ファイルは最初にサーバーにロードされ、次にストレージサーバーにプッシュされることがわかっているためです。

このようなものを設計するためのより良い方法は何ですか? 私たちはこれを .NET で行うことを好みますが、適切であれば別のテクノロジを選択することもできます。

4

1 に答える 1

0

それは、最適化しようとしているものによって異なります。このアプローチは、バックエンド ストレージ API が変更された場合に、クライアント アプリケーションの開発時間を最適化します。バックエンド ストレージ API が頻繁に変更されることが予想される場合、これは有効な最適化であり、正しい方向に進んでいると言えます。私は WCF のようなものを使用します (データベースなどの構造化データを対象とした WCF DataServices とは限りません)。

ただし、バックエンド ストレージ API が頻繁に変更されない場合は、追加のラッパー レイヤーの追加オーバーヘッドに見合う価値がない可能性があります。

それが私にとって決定的な質問です。バックエンド ストレージ API はどのくらいの頻度で変更されると予想されますか?

于 2013-03-26T16:34:54.057 に答える