5

私は derby に非常に興味をそそられ、昨夜はドキュメンテーションを読んで過ごしました。私の現在のアーキテクチャに関する考えは、対応するリッチ クライアント アプリケーション、または API にアクセスできる他のユーザーによって使用される RESTful API の構築に非常に向いています。

Derby が私に感銘を与えたのは、速度を重視しているだけでなく、Web が想定している (ページに一致する URL を使用する) のと非常によく似た機能を備えているからです。しかし、最近では製品に適合するモバイル アプリケーションを作成しようとする動きがあり、モバイルとブラウザの両方の領域で開発したい場合は、API が必要になるようです。

私の質問は 2 つあります。

  1. derby を使用して API とやり取りし、基本的に API アダプターを作成し、それを mongoadapter と交換することができます。私はアダプターを見ていませんが、ドキュメントはアダプターを書くことはそれほど難しくないとほのめかしています。あるいは、accepts ヘッダーが json を要求する場合、derby は API 呼び出しに対する json 応答を生成できます。そうすれば、Web アプリケーションを提供するとともに、API としての役割を果たすことができます。

  2. derby は全体としてアプリケーションと見なされるべきであり、他のアプリケーション (モバイルなど) にはまったく使用されません。つまり、ブラウザーとモバイル アプリの共通要素は、API ではなくデータベースです。API を共通要素として持たないことの欠点は、機能がアプリ間で一貫していない可能性があることです (機能の量ではなく、一方がバグであり、他方がバグではない可能性があります)。

私は次のプロジェクトで derby を使用したいと思っていますが、それが仕事のツールであるかどうかを明確にする必要があります。(ちなみに、プロジェクトは大きな Web アプリケーションになりますが、モバイル統合が必要です。API を持つことも素晴らしいアイデアかもしれませんが、その有用性についてはまだわかりません)

4

1 に答える 1

1

  1. APIアプリ（データが実際に保存されている場所）と通信するためにダービー用のアダプターを作成できると思いますが、このアダプターには事前定義されたメソッドがあり、APIを反映しません。そのため、ビジネス ロジックはおそらく重複し (ダービー アプリと API アプリ)、このソリューションから多くを得ることができません。

  2. derby を api-app として使用することをお勧めします。バージョン 0.6 (近日公開予定) から、サーバー側なしでクライアント側の derby アプリを使用できます。つまり、たとえば phonegap で使用できます。また、derby には、share.js に基づく競合解決機能を備えたクライアント同期が組み込まれています。「そのまま」の Web および phonegap アプリに使用できますが、ネイティブ モバイル アプリの場合は、それを使用するために share.js クライアントを作成する必要があります。また、share.js に組み込みの REST API があるか、高速ルートに基づいて API を簡単に実装できます。したがって、derby は API、Web、phonegap アプリに最適で、モバイル アプリにも適しています。

于 2013-11-16T10:14:17.800 に答える