12

私は現在、デバイスとチャネル (ユーザーの種類と場所) に合わせて調整された複数の異なるフロントエンド プレゼンテーションを持つマルチチャネル コマース システムのアーキテクチャを設計しています。私が直面している課題は、フロントエンド プレゼンテーション層での重複を減らす方法でコア コマース プラットフォームを開発していることをどのように保証するかということです。

サポートが必要なさまざまなフロントエンド プレゼンテーション層のサンプルを次に示します。

  • 消費者向けの従来のデスクトップベースの Web サイト
  • 消費者向けにモバイルに最適化されたウェブサイト
  • コンシューマー向けのネイティブ モバイル アプリケーション (iOS/Android)
  • カスタマー サポート担当者向けのカスタマー サポート センター Web サイト
  • 実店舗で買い物をする消費者向けのインストア キオスク ベースの Web サイト
  • その他 (Angular、PHP、.NET などのさまざまなテクノロジを利用したマイクロサイトおよびその他)

今では、階層化されたアーキテクチャ (プレゼンテーション、ビジネス、データ層) に関するベスト プラクティスと、1 つのアプリ (MVC、バリデーター、インターセプターなど) 内のフロントエンドの課題に対処するための一般的な設計パターンを理解しています。ただし、これらの原則のいずれも、複数のフロントエンドのサポートに直面した場合に、プレゼンテーション固有のビジネス ロジックをカプセル化する方法と場所を説明していません。

ですから、私の質問は、各フロントエンド アプリケーションがフロントエンド ビジネス ロジックを複製しないようにするために、そのようなシステムを開発する際に従うべきいくつかの良い慣行と原則は何ですか?

私はこれまで、さまざまなアプローチを使用して、このような要件を持つ多くのアプリケーションを開発してきました...かなりうまく機能するものもあれば、それほどうまく機能しないものもありました。しかし、よくある問題の解決策を発明しているように感じ、活用すべきベスト プラクティスと原則がいくつかあるはずだと感じるたびに.

私が尋ねている特定の課題の簡単な例

すべてのフロントエンド アプリケーションは、新しい顧客アカウントを登録する機能をサポートする必要があります。登録フォームには、電子メール、パスワード、顧客の住所情報 (番地、都市、郵便番号など) などの情報が含まれます。フォームが送信されると、システムでアカウントが作成され、確認メールがユーザーに送信される前に、特定の簡単な検証と重要な検証が行われる必要があります。例えば：

  • 電子メール アドレス パターンの検証規則
  • メールアドレスがシステムに存在しないことを確認する
  • パスワードの複雑さのルール
  • 住所の検証 (サードパーティの住所検証/標準化システムによる)

ほとんどの場合、これらの検証ルールはすべてのフロントエンド システムに適用する必要がありますが、各フロントエンドの登録フローはわずかに異なり、フィールドのサブセットのみが含まれる場合があります。では、各フロントエンドが登録を適切に検証して処理するために必要なさまざまな手順を繰り返さないように、フロントエンドに API を提供するための良い方法は何ですか? たとえば、パスワードの複雑さのルールやアドレスの検証ルールなどを変更することにした場合、この新しい検証ロジックを使用してさまざまなフロントエンド アプリケーションをすべて変更する必要がないように、システムをどのように設計するのが最善でしょうか。

明確にするために、すべてのフロントエンドで共有されるコア ビジネス ロジック (つまり、アカウント作成サービス、住所検証サービス、アカウント ルックアップ サービスなど) をどこに配置するかについては心配していません。これらのパターンは、ブログ、本、およびフォーラムで一般的に議論されています。私の質問は、一般的にプレゼンテーション層に密接に結合されているビジネス ロジックに特に関連しています。いつも頭に浮かぶいくつかの質問。

  • フォームの検証や Web サービスを介した処理など、すべてのフロントエンド操作をサポートするプレゼンテーション サービス レイヤーを提供する必要がありますか? または、「2 つのフロントエンドは同じではない」ため、各フロントエンドがプレゼンテーション ロジックを所有する必要がありますか?
  • プレゼンテーション サービス レイヤーを作成する場合、各フロントエンドの微妙な違いに対処するサービスをどのように提供しますか? これらのフロントエンドごとに異なるサービス/エンドポイントを提供しますか?それとも、各フロントエンドがサービスを呼び出すときに渡す異なる「コンテキスト」を提供するだけですか?
  • このプレゼンテーション サービス レイヤーは、エラー メッセージを制御し、コンテキストを認識した適切なメッセージを各フロントエンドに返しますか? それとも、エラー コードを返してフロントエンドに所有させるべきでしょうか?
  • 等
4

2 に答える 2

2

特に異なるテクノロジーや環境 (PHP、JS、ネイティブ アプリ) を混在させている場合は、すべてのフロントエンドで一貫した検証ルールを設定する魔法のような方法はありません。検証ルールが複雑な場合、それを実装するコードは常に複雑になります。

できることは、検証をコア機能にすることです。プレゼンテーション レイヤーのすべての検証を取り除き、すべてのフロントエンドで使用される共通のアプリケーション レイヤーに移動できます。このように、プレゼンテーションにはフォームがあり、それをサーバーに送信して、ユーザーがフォームに入力している間に検証エラーを取得します。これは、Web からの AJAX またはネイティブ アプリからの REST API 呼び出しを使用して実行できます。正しく行われれば、ユーザー エクスペリエンスが損なわれることはありません。

このような場合には常にトレードオフがあります。検証コードの保守に費やす時間が少なくなりますが、応答性やユーザー エクスペリエンスがわずかに低下します。

于 2019-02-10T09:35:04.070 に答える
-1

あなたの質問を正しく理解していれば、次のようにします。

戦略パターンを使用して、抽象化に従って各プレゼンテーションを実装します。Factoryを使用して、具体的な戦略をインスタンス化します。MVC を使用して階層を分離し、Observerを使用してビュー レイヤーの戦略を更新します。

それが役に立てば幸い。

于 2013-12-05T17:18:56.390 に答える