バージョニングと再利用

New Applicationウィザードは、新しいアプリケーションに2つのOrgレイヤーのルールセットを自動的に追加します（OrgおよびOrgInt）。 デフォルトでは、これらのルールセットは、ルールセット検証を使用するよう設定されています。 追加のアプリケーションを作成し、Orgレイヤーにルールを追加すると、Orgレイヤーにさらにルールセットを追加する必要が生じる場合があります。 最終的に、Orgレイヤーで多数のルールセットが特殊化されると考えられます。 Orgレイヤーのルールセットの依存関係を維持しなくても済むように、Orgレイヤーのルールセットがアプリケーション検証を使用するよう設定できます。 これにより、複数のアプリケーションが同じアプリケーションベースのルールセットを参照する可能性が高まり、警告を発します。 Orgレイヤーのルールセットを組み込みアプリケーションとしてパッケージ化することで、これらの問題を解決できます。

ルール管理はコンポーネント内の観点から見て簡素化されると同時に、コンポーネントクライアントの観点から見ると、コンポーネントがバージョニングされると複雑さは増します。

たとえば、組み込みアプリケーション内のルールを大きく変更した場合に、その組み込みアプリケーションはその上に構築されたアプリケーションとの整合性が保てなくなる可能性があります。 たとえば、組み込みアプリケーション内のバリデートルールを更新すると、追加されたプロパティが値を持つことがあります。 これは、その上に構築されたアプリケーションにとって問題です。 この例では、変更をデプロイする前に、組み込みアプリケーションのバージョンの更新を検討する必要があります。

アプリケーションをバージョニングする理由は以下のとおりです。

• アプリケーションが、アップデートされたバージョンの組み込みアプリケーションを使用している。
• アプリケーションルールセットのリストにあるルールセットが、バージョンニング、追加、または削除された。

アプリケーションのバージョニングを行うと、次の事項を管理できます。

• アプリケーションが指定したルールセットバージョンのパッチレベル
• アプリケーションの組み込みアプリケーションのバージョン

また、不正なアップデートを防ぐために、アプリケーションをロックすることもできます。

アプリケーションのバージョンを上げないことには、正当な理由があります。 変更は、親アプリケーションにより使用されないルールの追加を伴います。 たとえば、検証されないプロパティ、またはRule-File-Binaryルールの追加は、親アプリケーションに影響を与えません。

ユーティリティコードは再利用可能な関数およびデータトランスフォームで構成されています。 特殊化したルールセットに、関数およびデータトランスフォームなどの再利用可能なユーティリティコードを配置すると、組み込みアプリケーションに追加できます。 どのバージョンの親アプリケーションでも、そのユーティリティコードにアクセスできるようになります。