1

アプリケーションのどの部分がコーディングされていませんか? 最も明白な例の 1 つは DB 資格情報であると思います。それらをハードコーディングするのは良くないと考えられています。ほとんどの場合、何かを外部化するかコード化するかを決めるのは簡単です。私にとって、ルールは単純です。次の場合、アプリケーションの一部を外部化する必要があります。

  1. 開発者以外でも変更できますし、変更する必要がありますが、UI で定義されたアプリケーション設定 (DB 資格情報、サービス URL など) に含まれることはあまりありません。
  2. プログラミング言語を必要とせず、コード化（ローカリゼーション）が不自然に見える

追加するものはありますか？

これは、 spring cfg に関するこの質問に少し関連しています。Spring 構成は、私の実践では開発者以外の誰も変更しないため、あまり明白な例ではないように思えます。そして、外部化の道は、プロジェクト全体がコード化されずに「構成」されるまで、あなたを遠くに連れて行く可能性があります。

したがって、コード化されていない何かを構成することで利益を得たときの経験からいくつかの例をここに投稿してください-春の依存性注入構成など.そして、春を使用する場合-再コンパイルせずに構成が変更される頻度はどれくらいですか?

4

11 に答える 11

5

アプリケーションの異なる展開間で異なる必要があるもの。つまり、環境に固有のものです。

例は次のとおりです。

  • データベース接続文字列
  • Web または WCF サービスの URL
  • ロギング構成
于 2008-09-25T17:47:30.837 に答える
3

アプリケーションが使用する「データ」であり、インストール場所によって変わる可能性のある情報。のようなもの：

  • 電子メールの送信に使用されるSMTPメールサーバー
  • データベース接続文字列
  • アプリが使用するファイルの場所/フォルダーへのパス
  • FTPサーバーと接続情報
  • 認証に使用されるActiveDirectoryサーバー
  • アプリケーションに表示される外部情報ソースへのリンク
  • 警告限界値
  • データ入力フィールドに使用できる文字を制限するために使用される正規表現フィルターも配置しました。
于 2008-09-25T18:04:40.407 に答える
2

明らかな変更内容 (パス、サーバー、ポートなど) に加えて、合理的に変更できるものは何でも簡単に変更できるはずだと主張する人もいます。たとえば、ビジネス ロジック (aルールエンジン)。

次に、「構成ファイル」でルールを定義します。これは、汎用言語ではなくDSLでプログラミングすることと同じです。ドメインに近いため、より簡単で保守しやすく、そうでなければ新しいビルドが必要になるものを簡単に変更できるという利点があります。

これの背後にある主な議論は、あなたが決して変わらないと思っていたことが、それにもかかわらず常に変化するということです.

于 2008-09-25T17:54:59.993 に答える
1

私はSpringを使用して、GUI（トランザクションスイッチ）を持たないJ2SEアプリケーションのすべてのBeanを配線します。そうすれば、コーディングを変えることなく、デプロイメントごとに異なる構成を設定するのが非常に簡単になります（これはさまざまな国で実行されます）。プレーンJDBC（またはSpring JDBC）を使用する場合、私が持っているもう1つのことは、すべてのSQLステートメントをコードとは別に管理することです。プロパティファイルやXMLなどのように、ステートメントを使用するBeanのStringプロパティとしても使用できます（DAOなど、ステートメントを使用するBeanが1つしかない場合）。

于 2008-12-01T15:29:51.190 に答える
1

構成ファイルには次のものが含まれている必要があります。

  • 展開の詳細
    • DBクレデンシャル
    • ファイルパス
    • ホスト名
  • 多くの場所で使用されているが、変更される可能性のあるもの
    • 連絡先メールアドレス
  • GUIにないオプション

最後のものは少し制限がありませんが、非常に重要です。クライアントが将来変更したいと思う可能性のある変数を予測することは非常に有用であることがわかりました。変更の頻度が低い場合は、私または彼らが構成ファイルを編集できます。頻繁に発生する場合は、ハードコーディングされていないGUIにオプションを追加するのは簡単です。

于 2008-09-25T18:00:26.827 に答える
1

データの永続性のためにSpring JDBCまたはvanilla JDBCを使用します。ここでは、すべてのSQLをJavaコードから外部化することを決定したため、SQLクエリのチューニングと最適化の点でより扱いやすくなり、ジャバコード。

于 2009-05-14T14:04:44.127 に答える
1

私はあなたの 2 つの条件に同意します。

  1. Windows または Windows Mobile アプリケーションの一部として構成ファイルを含めることはめったにありません (Web アプリはい)。
  2. エンドユーザーが微調整することを意図した構成ファイルを含めたとしても、それは確かに XML ではありません。
于 2008-09-25T17:51:16.880 に答える
1

パスとサーバー名/アドレスが思い浮かびます..

于 2008-09-25T17:46:37.750 に答える
1

暗号化キーも追加します（それ自体は暗号化する必要があります）...

基本的に経験則は、通常の機能操作の前にアプリケーションが必要とする情報であり、手元にある必要があるデータです (つまり、ローカルでネットワーク化されていない)。
このデータは動的に変化したり、大量に変化したりしてはならないことに注意してください。それ以外の場合は、データベースに存在する必要があります。

于 2008-09-25T19:24:19.247 に答える
1

従業員は出入りできるため、従業員の電子メール/名前... (ただし、通常、それらをアプリケーションから遠ざけるようにしてください)

于 2008-09-25T17:55:50.927 に答える
1

Spring アプリでは、実際には次の 2 種類の構成を区別します。

  1. 「展開時」の問題または「環境固有」のプロパティ ファイルに外部化された項目: サーバー IP アドレス、ファイル システムの場所など

  2. アプリケーション全体の構造を示したり、AOP を介して動作を適用したりするなど、多くのことを実行できる Spring XML 構成。

于 2008-11-29T07:55:04.230 に答える