WebとAPIの間でビジネスロジックを再利用する
APIを介して接続するWebサイトと2つのモバイルアプリがあります。すべてのプラットフォームがまったく同じことを行います。現在、構造は次のとおりです。
- ウェブサイト。 Webサイトのモデル、コントローラー、ビューを管理します。また、すべてのバックグラウンドタスクを実行します。したがって、ユーザーが場所を作成すると、すべてがこのコードで実行されます。
- API。モデル、コントローラーを管理し、JSONを返します。ユーザーがモバイルアプリで場所を作成すると、その場所がここに作成されます。その後、他のフィールドを更新するためのバックグラウンドタスクを追加します。このバックグラウンドタスクはWebサイトによって実行されます。
すべてをやり直しているので、アプローチを改善する時が来ました。ビジネスロジックを再利用するための最良の方法はどれですか。場所の挿入/編集/削除、および1か所に関連する他のアクションをコーディングするだけで済みますか？
サービス指向のアプローチは良いアイデアですか？例：
- サービス。モデルがあり、DBから情報を取得、追加、更新、削除します。
- ウェブサイト。情報をサービスに送信し、HTMLをレンダリングします。
- API。サービスに情報を送信し、JSONを返します。
私が見つけたいくつかの問題：
- もっと初期の仕事？わからない..
- 動作が遅くなる可能性があります。何か経験はありますか？
メリット：
- Webとapiの両方のビジネスロジックが1か所にあります。
- スケーリングが簡単です。各ピースを異なるサーバーに配置できます。
その他のソリューション
- コードを複製し、何も忘れないように注意してください（テストを実行してください！）
- 一部のコードを複製しますが、関連するフィールドを更新し、他のもの（電子メール、インデックス作成など）を実行するバックグラウンドタスクを実行します
「小さな」詳細は、現在のところバックエンドの1.3人です;）
私は以前に（何度も）これに遭遇しました、そして私が優先してやったことは次のとおりです：
BLをウェブサイトから外します。 WebサイトをAPIの利用者にします。 WebサイトをAPIの他のクライアントとして扱います。あなたのAPI [〜＃〜] is [〜＃〜]サービス。
Webサイトだけに特別なAPIメソッドが必要だと思ったら、もう一度考えてみてください。ガチョウにとっては、ガンダーにとっても良いことです。あなたが本当にウェブサイトのために本当に特別な機能を本当に必要としているなら、私が実際に見つけたのは「ユーザープロファイル」の違いであり、したがってこれはAPIがまだ「特別な」機能をサポートするはずの状況ですが、承認を介してそれらを制御します。
納得できませんか？
パラダイムをさらに一歩進めます...
電話アプリは、バイトコードが実行されるプラットフォームで実行されており、アプリは電話内にあり、HTTP/JSONを介してAPIサービスを利用します
ウェブサイトは、HTML + Javascriptが実行されるプラットフォームで実行されるアプリであり、アプリはブラウザーに存在し、HTTP/JSONを介してAPIサービスを利用します
同じ同じ！
それをタブレット、TV、その他の電話プラットフォーム、プラグイン、サードパーティのアプリ、マッシュアップなどに拡張してください...
多くの異なるユーザーエクスペリエンスがすべて共通のAPIに接続されています。
あなたのアプリIS API。ウェブサイトは（多くの）クライアントの1つにすぎません）
ここではかろうじて質問ですが、いくつかの考え：
あなたは尋ねます：「もっと最初の仕事？」何と比較して？このバックグラウンドタスクの要素は、セットアップのトラブルの原因となるようです。
バックグラウンドタスクソリューションは同じものになり、共通/共有コードを呼び出します。あなただけが間接的にそれを行います。それはどのようにして、より優れた、またはより保守可能なソリューションになるのでしょうか？
バックグラウンドタスクで主に作業すると、タスクの結果を知る必要があるシナリオも複雑になります。戻り値の待機と整理は負担となり、複雑さを増します。
次に、「遅くなる可能性があります。経験はありますか？」別のプロセスで処理されるようにバックグラウンドタスクを設定することは、タスクを直接かつ即座に（できれば同じプロセスで）呼び出すよりも速くなることは決してありません。
あなたが提案するスケーリングの利点は、プロセスの境界、またはさらに悪いネットワークの境界を絶えず越えなければならないことをもたらします。できればインプロセスサービスレイヤーを作成したいと思います。本当に必要な場合は、中間層を作成します。
私が考える限り、コードの重複は決して解決策ではありません。メンテナンスの災害を求めています。