0

現在、静的テキストを構成可能にする必要があるプロジェクトに取り組んでいます (ラベル、メッセージ、および検証エラーを含む)。最善のアプローチは何だろうと考えていました。このアプリは、ASP.NET MVC と C# 3.5 を使用して作成されています。このすべての静的な構成可能なテキストを、別のプロジェクトから MVC プロジェクトに供給する必要があります。グローバル リソースを使用するか、アプリケーションの起動時に読み込まれる XML ファイルを使用することを考えました。ところで、これはローカリゼーションに関するものではありません。また、エンドユーザーが静的テキストを構成することもできません。

4

5 に答える 5

1

Jamesが答えたように、AppSettingsとweb.configを使用できます。キーと値のペア構造を使用して、データベースに保存することもできます。

ただし、構成プロジェクトから ASP.Net MVC プロジェクトに取得する必要もあります。私は次のようにします：

  • 構成プロジェクトでサービス インターフェイスを作成する
  • ASP.Net MVC プロジェクトで Enterprise Library Caching を使用する
  • 値がキャッシュされているかどうかを確認する
  • そうでない場合は、構成から取得してキャッシュに保存します
于 2009-10-06T15:05:18.253 に答える
1

おそらく、一連の Resx ファイルを含む別のプロジェクトを作成することになるでしょう。これらは非常に扱いやすく、無料でローカリゼーションを提供します。ここから始めます。管理ツールを使用してオンザフライで編集する必要がある場合は、Rick Strahl のデータ駆動型プロバイダーのようなものを使用できます。これはおそらく、独自の DB 駆動設計を考え出すよりも優れたアプローチです。

テキストがいつどのように編集可能になるかを少し明確にする必要があることに同意します。

1 行または 2 行のテキストについて話している場合を除き、web.config および appsettings には絶対に近づかないでください。一般に、これは、他の人がアプリの再起動と一般的な構成の肥大化について述べている多くの理由から、良い考えではありません.

于 2009-10-06T16:31:00.607 に答える
0

ローカリゼーションは、実際にはこれを処理する適切な方法です。同じ問題を解決しています。単一の言語ファイルを提供するだけで済みます。欠点は、ローカリゼーション ビットが必ずしもエンド ユーザーが簡単に編集できるとは限らないことです。ここで答えるべき本当の質問は、「この情報をユーザーがどのように編集できるようになるか」という事実に私を駆り立てます。答えが「頻繁かつ簡単に」である場合は、データベースにある種の UI スニペット テーブルを作成し、それに応じて処理することをお勧めします。別の適切なオプションは、カスタム構成セクションを使用し、構成 API を使用して読み取り/書き込みを行うことです。また、必要に応じて手動で編集する XML ファイルを開いたままにします。

于 2009-10-06T15:19:05.877 に答える
0

アプリケーションの起動時に単一のロードで XML ファイルを使用します。

于 2009-10-06T15:21:53.920 に答える
0

Web.Config ファイルの AppSettings セクションに保存します。

于 2009-10-06T14:54:07.600 に答える