拡張機能の名前付けガイドライン

概要ガイダンス: プレフィックスを使用して競合を減らし、識別を向上させる

モデル要素に名前を付ける

モデル内のすべての要素には、インストール時にすべてのモデルにわたって一意の名前を付ける必要があります。 ただし、インストール時に、すべてのモデルの名前がわからず、モデルが一緒にインストールされる場合があります。 このような状況に対応するには、すべての要素名にソリューションに固有のプレフィックスを含めます。 モデルの要素に名前を付ける場合にこの接頭語を含めることで、名前の競合のリスクを大幅に軽減します。

• モデルに複数のソリューションが含まれている場合は、さまざまな接頭語によって、モデルでは、各ソリューションを識別できます。
• プレフィックスを慎重に選択して、他の当事者の他のモデルが要素に同じプレフィックスを使用するリスクを最小限に抑えます。

他のモデルで機能を拡張する場合、拡張する要素にはプレフィックスが既に含まれています。 ただし、名前に複数の連続するプレフィックスが含まれていないように、プレフィックスを拡張要素に追加しないでください。 代わりに、拡張要素に名前を付けるとき、プレフィックスまたは別の用語または省略形をインフィックスとして含めます。

拡張機能に名前を付ける

拡張要素は、テーブル拡張子、ビュー拡張子、またはフォーム拡張子など、他のモデルの拡張子と競合のリスクを最小限にする一意の名前を付ける必要があります。 競合のリスクを最小限に抑えるには、拡張を他のモデルの同じ要素に対する他の拡張機能と区別する用語、省略形、またはインフィックスを含めます。

• 拡張子要素があるモデルの名前、または拡張子が関連付けられている接頭語のいずれかを含めます。 たとえば、ウェアハウジング モジュールは HCMWorker テーブルを拡張し、他のすべての要素の名前で WHS 接頭語を使用します。 この場合、拡張機能に HCMWorker.WHSExtension という名前が付けられます。 モジュール内の他の要素に名前を付けるために使用されるプレフィックスは、名前にインフィックスとして挿入されます。 別の例として、拡張子が ContosoCustomizations モデルからの ContactPerson テーブルへのすべての拡張機能を含むことを意図している場合、ContosoCustomizations モデルの ContactPerson テーブルの拡張子は、ContactPerson.ContosoCustomizations という名前が付けられます。 開発者ツールでは、モデル名が既に一意である必要があるため、既定ではモデルの名前が拡張機能名として使用されます。
• 拡張子名を <Element that is being extended>.Extension としないでください。 たとえば、競合のリスクが大きすぎるため、InventLocation テーブルの拡張クラスには、InventLocation.Extension という名前を付ける必要はありません。

拡張クラスの名前を付ける

テーブル、クラス、またはその他の要素のロジックを拡張する拡張クラスには、すべてのモデルのすべての型で一意の名前が必要です。 拡張クラス名には、拡張する型の名前が含まれていることをお勧めします。 ただし、名前には、用語、省略形、またはクラスを他のタイプと区別する接頭語も含まれる必要があります。

• 拡張クラスの名前を拡張する型の名前で開始し、 名前を _Extension という用語で終了します。 したがって、ContactPerson テーブルを拡張する拡張クラスは、 ContactPerson という名前で始まり、 _Extensionで終わります。 たとえば、1 つの拡張クラスに ContactPersonWHS_Extension という名前が付けられます。
• 拡張子要素があるモデルの名前、または拡張子が関連付けられている接頭語のいずれかを含めます。 たとえば、ウェアハウジング モジュールは ContactPerson テーブルを拡張する拡張クラスを使用し、他のすべての要素の名前で WHS 接頭語を使用します。 この場合、拡張クラスに ContactPersonWHS_Extension という名前が付けられます。 モジュール内の他の要素に名前を付けるために使用されるプレフィックスは、名前にインフィックスとして挿入されます。 別の例として、拡張クラスがアプリケーション スイート モデルの ContactPerson テーブルのすべての拡張機能を含むことを意図している場合、アプリケーション スイート モデルの ContactPerson テーブル を増補する拡張クラスは、ContactPersonApplicationSuite_Extension という名前が付けられます。
• コードで宣言できない要素のクラス拡張を作成する場合は、追加の要素タイプ情報を追加を検討します (Forms、DataSources、FormControls など)。 たとえば、CustTableFormWHS_Extension は CustTable フォームの拡張です。
• 拡張子名を <Element that is being extended>_Extension としないでください。 たとえば、競合のリスクが大きすぎるため、InventLocation テーブルを補強する拡張クラスには、InventLocation_Extension という名前を付ける必要はありません。

拡張で追加されるフィールド、フィールド グループ、インデックス、関係、およびメタデータ要素に名前を付ける

拡張で追加するフィールド、フィールド グループ、インデックス、リレーション、およびメタデータ要素には、拡張する要素とその他の拡張要素の両方で一意の名前が必要です。 そのため、モデル間の競合のリスクを最小限に抑える プレフィックスを含めます 。 さらに、これらの成果物を簡単に理解できるように、明確な用語と省略形を使用します。

• メタデータ ノードの名前の先頭に接頭語、用語、または省略形を含めます。 たとえば、承認する作業者の外部キー フィールドはテーブルの拡張機能の一部として追加され、WHS はホスト モデル内の他の要素に専用である接頭語の 1 つです。 この場合、フィールドに WHSApprovingWorker という名前が付けられます。

拡張クラスに追加される変数およびメソッドの名前を付ける

拡張クラスに追加する変数とメソッドには、拡張する型と、同じ型を拡張する他のすべての拡張クラスの両方で一意の名前が必要です。 変数およびメソッドに対して、一意で判読可能な名前を作成します。 一意の名前を作成できない場合は、プレフィックスを追加して、モデル間の競合のリスクを最小限に抑えます。

• 変数およびメソッドに対して、一意で判読可能な名前を作成します。 たとえば、機能の領域が一部のローカル倉庫拡張機能のサポートに関連している場合、承認する作業者のクラス レベルの変数には、approvingWorkerForLocalWarehouse という名前が付けられます。 機能の同一領域に対する approveWork メソッドには、approveWorkForLocalWarehouse という名前が付けられます。

• 一意で読み取り可能な名前を作成できない場合は、メンバー変数またはメソッド名の先頭にプレフィックス、用語、または省略形を追加します。 たとえば、WHS がモデル内の他の要素が使用する接頭辞の 1 つである場合、承認ワーカーのクラス レベル メンバー変数の名前は whsApprovingWorker になることがあります。 WHS がホスティング モデル内の他の要素が使用する接頭辞である場合、approveWork メソッドの名前は whsApproveWork になることがあります。

• 複数の拡張機能が同じ用語を使用する可能性がある、または基本機能が将来のリリースで同じ名前で拡張されるリスクが高いため、汎用名を使用しないでください。 競合する可能性のある名前の例としては、 承認者、 遅延、 グループ、 ルックアップ、 プロセスがあります。