マスター作業版数設計パターン

このパターンにより、通常は、互いに連動して機能する 2 つのオブジェクトが生成されます。一方がなければ、もう一方は存在せず、無効となります。ルートには、以下の基本的な抽象があります。

マスター化インタフェースは、作業版数適用済みインタフェースと関連するプラグアンドプレイコンポーネントを抽象化します。この目的は、ビジネスモデルで、マスター化インタフェースを継承することにより、オブジェクトがマスターであるとアサートすることです。このアサーションにより、バージョン制御サービスの API. を使用してビジネスオブジェクトをマスター化できます。ビジネスオブジェクトは、そのインスタンスを作業版数化するために、このオブジェクト自体をマスター化されたオブジェクトとしてアサートする必要があります。

作業版数適用済みインタフェースは、マスター化インタフェースと関連するプラグアンドプレイコンポーネントを抽象化します。この目的は、ビジネスモデルで、作業版数適用済みインタフェースを継承することにより、オブジェクトが作業版数 (インスタンス) であるとアサートすることです。このアサーションにより、マスターがある場合は、バージョン制御サービスの API を使用してビジネスオブジェクトを徐々に置き換えたり、ロールバックおよびロールアップしたりできます。このビジネスオブジェクトを徐々に変更できるようにするために、このオブジェクト自体を一種の作業版数適用済みオブジェクトとしてアサートする必要があります。

以下のレベルのマスターと作業版数の組み合わせでは、一般的な [仮想] 企業の視点から、適用可能なすべての機能をともに引き出す (アサートする) 抽象エンティティを定義します。その下のレベルはさらに具象になります。ここで、EnterpriseItemMaster は具象ですが、EnterpriseItem は具象ではありません。マスターと作業版数との関係が正確な名前の付いた役割によってオーバーライドされるのは、このレベルです。ただし、マスター内での作業版数の多重度を特殊化してさらに制限することもできます。また、この関係でそれ自体を外部キーとして再度指定し、マスターを作業版数から自動ナビゲーションすることもできます。したがって、作業版数がデータベースから呼び出された場合は、そのマスターもデータベースのビューを通して、1 つの SQL ステートメントで呼び出されます。

このレベルの作業版数は、この種の外部キーとの関係のために具象である必要はありません。また、具象クラスの自動ナビゲーションには、抽象クラスとしてのもう 1 つの側面がある場合があります。

最下位のレベルでは、EnterpriseItem の具体的な特殊機能がすべて存在します。これらすべての特殊機能は外部キーを継承し、EnterpriseItem から関係を自動ナビゲーションします。したがって、それぞれが固有のデータベースビューとともに生成されるので、3 つのデータベースビューが EnterpriseItem1、EnterpriseItem2、および EnterpriseItem3 用に生成されます。