REST APIとデスクトップアプリケーションの直接DB呼び出し
現在、会社で使用するアプリケーションを計画しています。デスクトップアプリケーションをビルドするために必要です。現在のところ、近い将来、アプリケーションがモバイルまたはブラウザーで利用可能になるかどうかは不明です。
私には2つの可能性があります。
デスクトップアプリケーションから直接データベースにアクセスする
REST APIを作成し、これに接続します
REST APIを使用できますか？可能であることはわかっていますが、「正しい」方法ですか？（ベストプラクティス）
REST APIを直接作成することには、いくつかの（可能な）利点と欠点があります。
欠点：
- 開発に時間がかかる
- より複雑
- サーバーはより多くの作業を行います
- セキュリティ上の問題
- もっとゆっくり？ （サーバーとデスクトップアプリケーションは同じネットワーク上にあります）
利点：
- 他のプラットフォームへの移行は簡単です
- ビジネスロジックは、データベースを直接呼び出す場合にも必要です。開発にそれほど時間はかかりません
- 複雑さについても同じ
- セキュリティー（コメントのtkauslで言及）
- 保守性（コメントのWindRavenで言及）
数百万のレコードを含む巨大なデータベースを備えた大規模なアプリケーションの場合、すぐに、単純な選択、更新、挿入、削除だけでは十分ではないことに気付くでしょう。
だからあなたは別の方法で考え始めます。プロシージャとトリガーを作成して、より複雑なものをデータベースで直接処理しますが、これはあまり良くありません。 CRUD操作を実行すると、データベースは優れたパフォーマンスを発揮します。長い手順？それほどではありません。
手順の問題
プロシージャの概念をサポートしないデータベースに切り替えると想像してみてください。何をする？代わりにプロシージャをコードベースに移動する必要があり、Javaでプログラムすると、どのデータベースエンジンを選択しても、常にそこに留まることが確実になります。
言うまでもなく、プロシージャは通常ビジネスロジックの一部であり、コードベースとデータベース全体にビジネスロジックを適用することはお勧めできません。
理想的には、データベースと独自のビジネスルールを実装するクライアントとの間に常に仲介者がいる必要があります。データベースへの直接アクセスを提供することは良い考えではありません。これを行うと、アクセス権を持つユーザーはテーブルに直接アクセスでき、そこにあるデータでほとんど何でもできるからです。
短所
- 開発に時間がかかる：もちろん、新しいシステムを作成しています。これは、単にクライアントにデータベース接続文字列を与えて、クエリを作成させるよりも時間がかかります。
- より複雑：システムの複雑さ>データベースクエリの複雑さ。
- サーバーはより多くの作業を行います：必ずしもそうではありません。優れた設計、キャッシング、...を使用して、負荷をデータベースサーバーからメディエーターの1つに移動できます。
- 遅い：開発に関しては？はい。データを取得する際の速度についてはどうですか？いいえ。キャッシュ（2016年1月の時点で人気のある-などのメディエーター-Redis、Elasticsearchなど）を使用してメディエーターを最適化し、実際よりも速くデータを配信できます。プレーンデータベースクエリ。
メリット
- 他のプラットフォームへの移行は簡単です：新しいデータベースエンジンへの移行？絶対に。メディエーター全体を新しい言語に移行しますか？あんまり。
- データベースを直接呼び出す場合にもビジネスロジックが必要です。開発にそれほど時間はかかりません：前に説明したように、プロシージャの問題。
- Security：適切な認証を使用すると、メディエーターを持つことは、ユーザーにデータベースへの直接アクセスを許可するよりもはるかに安全です。ユーザーを必要なクエリのみを実行するエンドポイントに制限するためです。
- 保守性：メディエーターを持つことの最大の利点の1つ。クライアントが呼び出すAPIにバグがある場合は、修正し、修正をVCSリポジトリにプッシュし、修正を含む最新バージョンのVCSからメディエーターを構築します。すべてのクライアントは、修正を使用せずに突然修正を使用します。アップデートをダウンロードします。クエリがクライアントアプリケーションに直接格納されている場合、これを行うのは単に不可能です。その場合、クライアントはアプリケーションを更新する必要があります。
これについての私の意見は次のとおりです。あなたはウェブサービスを使いたいという正しい考えを持っていますが、あなたは間違った技術を使うことを計画しているかもしれません。
RESTと言うとき、私はあなたがAsp.Net WebApiについて話していると想定しています。これは、イントラネットアプリケーションでは不適切な技術です。 REST＆WebApiは素晴らしいですが、誤解しないでください。しかし、どんな内部アプリケーションにとっても、WCF Webサービスは私の控えめな意見に行く方法です。クライアントはクラスライブラリと同じようにサービスエンドポイント。つまり、デスクトップクライアントでXMLやJSONを処理するのではなく、クラスとオブジェクトを操作します。
とにかく、はい。あなたは正しい考えを持っています。 Webベースのクライアントが必要かどうかがわからない場合は、後で必要になったときに簡単に追加できるようにシステムを設計する必要があります。サービス指向アーキテクチャーを使用すると、さまざまなタイプのクライアントを追加する方がはるかに簡単です。
このように見てください、それは間違いなくが一般的なパターンであり、ベストプラクティスとして合理的に説明されているかもしれません。
プラットフォームによっては、ほとんど問題を解消するツールが見つかる可能性があります。Microsoftは接続されたアプリに対してODATAをサポートしており、学習曲線を上ると、データを簡単にフォーム化できます。
より実用的に-デスクトップアプリケーションのデータレイヤーに必要なAPIを定義し、そのAPIをコード化します。すべてのデータベースアクセスをそのAPIの背後に配置します。これにより、実際にアプリケーション開発の観点から物事が改善されます。その後、実際のデータベースアクセスコードの場所はそれほど重要ではなくなります（データベースに直接通信するコードによって同じAPIを実装できます）または、残りのエンドポイントを介してデータベースと間接的に対話するコードによって）。直接実装から始める場合、RESTバージョンは実質的に同じAPIのラッパーになるため、あまりペナルティが課されることはありません...
それはおそらく私がそれを作りたいほど単純ではありません-しかし、それは良いパターンです [〜＃〜] yagni [〜 ＃〜] ルート。