1

次のレイヤーでアプリを構築します。

  • WEB プレゼンテーション層
  • ビジネス ロジック層 - BLL - HTTP Web サービスを介して WEB UI から呼び出される
  • WindowsService - ランタイム - net.pipe を介して BLL から呼び出される

BLL は、他の顧客のシステムに統合するために、サード パーティから呼び出すこともできます。

ランタイムまたは BLL で発生する検証エラーがあるとします。翻訳を配置するのに適した場所:

  1. 例外メッセージで - UICulture を WEB 層から下位層に送信する必要があることを意味します
  2. BLL とランタイムはエラー コードまたはカスタム例外派生型を返し、変換は WEB UI レイヤーで実行されます
  3. 他の方法

SOA アーキテクチャで複数の言語をサポートするためのベスト プラクティスは何ですか?

編集:おそらくレイヤーの代わりに層という用語を使用する必要があります。

  • WEB UI 層は ASP.NET Web フォームに実装され、IIS の下のサーバー A に展開されます。
  • BLL とランタイムはサーバー B にデプロイされますが、プロセス境界によって分離されます (BLL は WCF サービスのために ASP.NET ワーカー プロセスの下で実行され、ランタイムは分離された Windows サービス プロセスとして実行されます)。
4

4 に答える 4

1

変換は、ビューに関連するため、プレゼンテーション レイヤーによって処理される必要があります。メッセージに追加できるコンテキストが多ければ多いほど、ビジネス ロジックはコンテキストを認識しない可能性があり、認識すべきでもありません。

私が使用したアプローチは次のとおりです。

  • ビジネス ロジックは、翻訳されたメッセージを取得するためのキーとしてリソース バンドルに使用できる、一意の定義済みエラー コードをスローします。

  • プレゼンテーション レイヤーは、一般的なプレゼンテーション レイヤー コードとは別に、すべてのエラー コードの変換を含むテキスト パッケージを保持します。


  • プレゼンテーション レイヤーは、ビジネス ロジックとテキスト パッケージの両方に依存します。

  • ビジネス ロジックのサード パーティ クライアント (Web サービスなど) は、標準エラー コードの変換が必要な場合に、テキスト パッケージを依存関係として含めることを選択できます。それ以外の場合は、ビジネス ロジックによってスローされたエラー コードを独自に処理できます。

于 2009-06-13T19:18:51.487 に答える
1

あなたが使用している .NET プラットフォームの詳細を私は知らないので、あなたの問題に対する私のアドバイスは一般的なものです。

あなたの質問から、2 つの異なる問題が見えます。

  1. Web プレゼンテーション レイヤーは言語に依存します。カスタム CSS、フォント、間隔、さらにはカスタム コンテンツが必要になります。これが必要ないことにだまされないでください。これは、Web アプリケーションを国際化するときに最初に犯す最大の間違いの 1 つです。言語には別のスタイルが必要です。したがって、テンプレート アプローチを使用している場合は、言語コンテンツのほとんどを言語依存のテンプレートに入れることができます。

  2. 問題の説明からすると、ローカライズされたエラー メッセージも処理する必要があるようです。これには 2 つのアプローチがあります。リソース ファイル ソリューションを使用して、エラーがスローされたときにローカライズする言語ファイルを用意できます。もう 1 つの方法は、エラー メッセージで共通の識別子とパラメーターを使用し、別のレイヤーでメッセージをキャッチしてローカライズすることです。私自身は、前者の方が簡単なので、前者のソリューションを好みます。

また、エラー メッセージをログ ファイルに書き込む場合は、エラー メッセージが開発者が読める言語であることも忘れないでください。同様に、GUI でユーザーに表示されるエラーについては、ユーザーの言語を話さない開発者に対して、ユーザーがエラーを特定できる何らかの方法が必要になります。これは数字を使用して行うことができます - 私は のような短いキーを使用することを好みますDATABASE_ERROR_BAD_QUERY。

于 2009-04-21T15:42:28.650 に答える
0

アプリケーションの構造によっては、次の 2 つの場所で国際化が必要になる場合があります。

1)ソフトウェア自体。 メニュー、ダイアログ、メッセージ、ラベル、レポートなど

2)コンテンツ。複数の言語で実行されているアプリケーションは、複数の言語でコンテンツを処理する必要がある可能性があります。

管理ツールとパブリッシング ロジックを異なるレイヤーに分離することは、うまくいきました (これまでのところ)。

まず、言語翻訳の管理および生成ロジック (リソース バンドルなど) をビジネス ロジックに配置することを検討します。 したがって、すべての翻訳について、マスター言語 (英語) からすべての言語でシステムに追加されたすべてのデータ エントリをすばやく同期し、入力して管理する方法が必要です。したがって、たとえばリソース バンドルを使用している場合は、すべての言語のデータベースから rb ファイルを生成します。

次に、プレゼンテーション層で言語翻訳ロジックを公開します。プレゼンテーションとフォーマットに関係があります。日付、時刻、通貨などのローカライズで問題が発生することは避けられませんが、ここではかなりうまく処理できます。これらのものを制限として公開するために独自のライブラリを作成する場合と作成しない場合があります。または、プログラミング言語の柔軟性が許可する場合と許可しない場合があります。

詳細を教えていただければ、ここにいるすべての人から得られる他の洞察があると確信しています。

幸運を！

于 2009-06-13T20:50:42.483 に答える
0

あなたの WEB UI の定義はよくわかりません。MVC パターンを使用する場合、コントローラーは適切な言語バージョンを UI に表示するように配置され、テキスト自体はビュー レイヤーに配置されます。私が理解できなかったのは、あなたのアーキテクチャでコントローラーの役割を果たしているものです。BLL は、処理ロジックのみを含み、UI とサービス間の通信がないことを意味しますか? その場合、おそらく Web UI レイヤーにはローカライズ ロジックが含まれます。

また、プロジェクトで使用するテクノロジーにも大きく依存すると思います。たとえば、ASP.NET には、使用できる組み込みのローカリゼーション モデルがあります。それどころか、例として役立つべきだと言っているわけではありません.ASP.NETは懸念の分離を破っています。しかし、これは問題だと思います。あなたの場合のように、さまざまなカスタム アーキテクチャ モデルでは非常に異なるソリューションになるでしょう。

于 2009-04-21T15:30:01.907 に答える