デスクトップアプリケーションでのREST APIと直接DB呼び出し

現在、会社で使用するアプリケーションを計画しています。デスクトップアプリケーションをビルドするために必要です。現在のところ、近い将来、アプリケーションがモバイルまたはブラウザーで利用可能になるかどうかは不明です。

私には2つの可能性があります。

1. デスクトップアプリケーションから直接データベースにアクセスする

2. REST APIを作成してこれに接続する

アプリケーションが社内のデスクトップアプリケーションのみである場合、REST APIを使用できますか？それが可能であることは知っていますが、「正しい」方法ですか？（ベストプラクティス）

REST APIを直接作成することには、いくつかの（可能な）利点と欠点があります。

短所：

• 開発に時間がかかる
• より複雑
• サーバーはより多くの作業を行います
• セキュリティ上の問題
• もっとゆっくり？（サーバーとデスクトップアプリケーションは同じネットワーク上にあります）

利点：

• 他のプラットフォームへの移行は簡単です
• ビジネスロジックは、データベースを直接呼び出す場合にも必要です。開発にそれほど時間はかかりません
• 複雑さについても同じ
• セキュリティ（コメントでtkauslが言及）
• 保守性（WindRavenによるコメントでの言及）

何百万ものレコードを含む巨大なデータベースを備えた大規模なアプリケーションの場合、すぐに、単純な選択、更新、挿入、削除だけでは十分ではないことに気付くでしょう。

だからあなたは別の方法で考え始めます。プロシージャとトリガーを作成して、より複雑なものをデータベースで直接処理しますが、これはあまり良くありません。CRUD操作を実行すると、データベースは優れたパフォーマンスを発揮します。長い手順？それほどではありません。

手順の問題

プロシージャの概念をサポートしないデータベースに切り替えると想像してみてください。何をする？代わりにプロシージャをコードベースに移動する必要があり、Javaなどでプログラムを作成すると、どのデータベースエンジンを選択しても、常にそこに留まることがかなり確実になります。

言うまでもなく、通常、プロシージャはビジネスロジックの一部であり、コードベースとデータベース全体にビジネスロジックを適用することはお勧めできません。

理想的には、データベースと独自のビジネスルールを実装するクライアントとの間に常に仲介者がいる必要があります。データベースへの直接アクセスを提供することは良い考えではありません。これを行うと、アクセス権を持つユーザーはテーブルに直接アクセスでき、そこにあるデータでほとんど何でもできるからです。

短所

• 開発に時間がかかります：もちろん、新しいシステムを作成しています。これは、クライアントにデータベース接続文字列を与えて、クエリを作成させるだけの場合よりも時間がかかります。
• より複雑：システムの複雑さ>データベースクエリの複雑さ。
• サーバーはより多くの作業を行います。必ずしもそうではありません。優れた設計、キャッシング、...を使用して、負荷をデータベースサーバーからメディエーターの1つに移動できます。
• 遅い：開発に関しては？はい。データを取得する際の速度についてはどうですか？いいえ。キャッシュ（2016年1月の時点で人気のある -Redis、Elasticsearchなど）を使用してメディエーターを最適化し、実際のデータベースクエリよりも高速にデータを配信できます。

メリット

• 他のプラットフォームへの移行は簡単です：新しいデータベースエンジンへの移行ですか？絶対に。メディエーター全体を新しい言語に移行しますか？あんまり。
• ビジネスロジックは、データベースを直接呼び出す場合にも必要です。開発にそれほど時間はかかりません。前に説明したように、手順の問題です。
• セキュリティ：適切な承認があれば、メディエーターはデータベースへの直接アクセスを許可するよりもはるかに安全です。必要なクエリのみを実行するエンドポイントにユーザーを制限するからです。
• 保守性：メディエーターを持つことの最大の利点の1つ。クライアントが呼び出すAPIにバグがある場合は、修正し、修正をVCSリポジトリにプッシュし、修正を含む最新バージョンのVCSからメディエーターを構築します。すべてのクライアントは、修正を使用せずに突然修正を使用します。アップデートをダウンロードします。クエリがクライアントアプリケーションに直接格納されている場合、これを行うのは単に不可能です。その場合、クライアントはアプリケーションを更新する必要があります。

これについての私の意見は次のとおりです。あなたはウェブサービスを使いたいという正しい考えを持っていますが、あなたは間違った技術を使うことを計画しているかもしれません。

RESTと言うとき、私はあなたがAsp.Net WebApiについて話していると想定しています。これは、イントラネットアプリケーションでは不適切な技術です。RESTとWebApiは素晴らしいです。誤解しないでください。しかし、どんな内部アプリケーションにとっても、WCF Webサービスは私の控えめな意見に行く方法です。これにより、クライアントはクラスライブラリと同じようにサービスエンドポイントを参照できます。つまり、デスクトップクライアントではXMLやJSONを扱っていません。クラスとオブジェクトを操作しています。

とにかく、はい。あなたは正しい考えを持っています。Webベースのクライアントが必要かどうかがわからない場合は、後で必要になったときに簡単に追加できるようにシステムを設計する必要があります。サービス指向アーキテクチャーを使用すると、さまざまなタイプのクライアントを追加する方がはるかに簡単です。

それをこのように見て、それは間違いである一般的なパターンと合理的にベストプラクティスとして記述される可能性があります。

プラットフォームによっては、ほとんど問題を解消するツールが見つかるかもしれません。Microsoftは接続されたアプリをODATAでサポートしているため、学習曲線を上ると簡単にデータをフォーム化できます。

より実用的に-デスクトップアプリケーションのデータレイヤーに必要なAPIを定義し、そのAPIをコード化します。すべてのデータベースアクセスをそのAPIの背後に配置します。これにより、実際にアプリケーション開発の観点から状況が改善されます。その後、実際のデータベースアクセスコードの場所はそれほど重要ではなくなります（同じAPIは、データベースと直接通信するコードによって実装できます）または、残りのエンドポイントを介してデータベースと間接的に対話するコードによって）。直接実装を開始すると、RESTバージョンは実質的に同じAPIのラッパーになるため、あまりペナルティが課されることはありません...

それはおそらく私がそれを作りたいほど単純ではありません-しかし、それは良いパターンです、それはYAGNIルートに遠く行くことなく必要な柔軟性をあなたに与えます。