モデルカスタマイズをオフにして機能を非推奨にする

この記事では、モデルのカスタマイズを無効にするプロセスについて説明します。 このプロセスに従うことで、モデルがオーバーレイヤー化できなくなります。 開発者は引き続きそのモデルを拡張できます。 この記事では、古い形式の機能を廃止する方法についても説明します。

通常、他のモデルに依存するモデルでアプリケーションを構築します。 少なくとも、モデルは、提供されているアプリケーション プラットフォーム モデルに依存します。 財務と運用アプリケーションは、Microsoft Azure クラウド プラットフォーム上で実行されます。 言い換えると、Microsoft が管理するデータ センターで、オンプレミスで実行されます。 Microsoft では、基本モデルで多数のベンダーからの変更をサポートできないため、アプリケーションはそれらのモデルで成果物を重ねることはできません。 したがって、アプリケーションをビルドするには、オーバーレイの代わりに拡張機能を使用する必要があります。 依存しているモデル内のすべての成果物はドキュメントの目的で利用できますが、他のユーザーの知的財産をコンパイルしてクラウドで実行することはできません。

カスタマイズをロックすること

オーバーレイヤーから拡張にモデルを移行するには、次の 3 つの手順が必要です。

1. オーバーレイヤーのインスタンスに警告としてフラグを設定するプロパティを設定します。 この手順は、"ソフト ロック" と呼ばれることもあります。
2. オーバーレイヤーではなく拡張機能を使用して警告を解決できる期間を使用します。
3. すべての警告を解決した後、オーバーレイヤリングをコンパイル失敗を引き起こす重大なエラーとします。 この手順は"ハード ロック" と呼ばれます。モデルがハード ロックされている場合、オーバーレイヤーに必要なツールをそのモデルに使用することはできません。 さらに、特定のパッケージに複数のモデルを含めることはできません。

現在、カスタマイズを無効にするプロパティを操作するためのツールは存在しません。 代わりに、次の例に示すように、 カスタマイズ XML 要素をモデル記述子ファイルに追加します。 モデル記述子ファイルは ...\<packages>\<package name>\Descriptor\<model name>.xml で見つけることができます。

<?xml version="1.0" encoding="utf-8"?>
<AxModelInfo xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Customization>DoNotAllow</Customization>
<Description>My cool locked application</Description>
...
<</AxModelInfo>

カスタマイズ設定には次の 3 つのレベルがあります。

• カスタマイズを許可する – Customization 要素を省略した場合、または指定したが、その中で [許可 ] というテキストを使用する場合は、制限はありません。
• ソフト ロック ソフト ロックが必要な場合、カスタマイズ 要素内の AllowAndWarn というテキストを使用してください。
• 確定ロック – モデルのカスタマイズを無効にするには、前の例に示すように、カスタマイズ要素内に DoNotAllow というテキストを使用します。

プラットフォームの下位互換性

依存プラットフォーム モデルの新しいバージョンがインストールされている場合でも、アプリケーションは実行を続ける必要があります。 そのため、プラットフォームでは、これらのプラットフォーム モデルに対するすべての変更に対して下位互換性のための厳密な要件が適用されます。 この点は、例によってより明確になります。 この例では、次のクラスを含むベース モデル M があります。

public void DoSomething(int arg)
{
    // Do great stuff
}

モデル M に依存するモデルでは、DoSomething クラスが提供するすべての便利な機能を活用したいと考えるでしょう。 そのため、次のコードを使用します。

{
    var c = new SomeClass();
    c.DoSomething(42);
}

後で、仕入先 (Microsoft など) が依存するモデル (モデル M) の新しく更新されたバージョンをリリースします。 このモデルがリリースされると、再コンパイルせずに実行する必要があるため、プラットフォームはパブリック インターフェイスをサポートする必要があります。 次のコードに示すように、別のパラメーターを追加してメソッドシグネチャが変更されるとします。

public void DoSomething(int arg, str anotherArg)
{
    // Do greater stuff
}

この場合、アプリは中断されます。 共通言語ランタイム (CLR) はメソッドを呼び出すことはできません。これは、呼び出しで想定されるパラメーター プロファイルが呼び出し先のパラメーター プロファイルと同じでないためです (呼び出し元のコードは 1 つのパラメーターを指定しましたが、2 つ必要になりました)。 そのため、パブリックに使用できるアイテムを制限することをお勧めします。 内容がプライベートである場合は、モデルの外部から誰も使用することはできません。 ただし、アーティファクトを内部化するというオプションもあります。 クラスまたはメソッドに 内部 修飾子を適用すると、成果物はモデル内でのみ表示され、外部からは到達できません。 基本的に、内部またはプライベートではないものは、モデルの外部から使用されることを前提とする必要があります。 したがって、永続的にサポートする必要があります。 絶対にパブリックまたは保護する必要がない限り、パブリックまたは保護されたものを作成しないでください。また、インターフェイスを使用して、モデルの境界外に関連しない実装の詳細を非表示にします。 内部可視性指定子を使用して (コードではなく) メタデータをマークする方法はありません。

内部機能のテスト

モデルのサーフェス領域を制限することで、カスタマイズを許可しないモデルの問題を修正できること、およびアプリケーションがスムーズに実行されることを保証できます。 しかし、内部化することで、コードをテストする能力が制限されてしまうと主張するかもしれません。 この状況を解決するには、テストするパッケージをテスト パッケージに通知します。 つまり、テスト パッケージは内部の項目にアクセスできます。 このソリューションを実装するには、次の例のように記述子ファイルを編集します。

<?xml version="1.0" encoding="utf-8"?>
<AxModelInfo xmlns:i=http://www.w3.org/2001/XMLSchema-instance>
<InternalsVisibleTo xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<d2p1:string>ExternalPackageName</d2p1:string>
</InternalsVisibleTo>
...
</AxModelInfo>

InternalsVisibleTo 要素に含めることにより、任意の数の外部パッケージを提供することができます。 この情報は、テストコードを含むパッケージではなく、テストするコードを含むパッケージ用です。 つまり、パッケージは情報を共有する人物を決定します。 > [!注]

AxModelInfo の下の要素はアルファベット順である必要があります。

非推奨機能

非推奨メソッド

パブリック ソース コードをサポートしなくなった場合があります。 前述のように、ユーザーが依存している可能性があるため、その成果物がプライベートまたは内部でない限り、コードから成果物を削除しないでください。 代わりに、 SysObsoleteAttribute 属性を使用して、コンシューマーがその成果物を使用しなくなったことを指定します。 次の 2 つのフェーズで、古いものとしてマークします。

1. 成果物の使用を警告としてマークすることを指定します。
2. 1 つまたは複数のリリース サイクルの後で、アーティファクトを使用することをエラーにします。

次の例では、DoSomething メソッドはモデルの最初のリリースで定義されています。

class SomeApi
{
    void DoSomething()
    {
        // Do great stuff
    }
}

2 番目のリリースでは、何かを実行するより良い方法があると判断しました。 したがって、新しい実装を追加し、古い実装を廃止します。

class SomeApi
{
    [SysObsolete("Use DoSomethingNew instead", false)]
    void DoSomething()
    {
        // Do great stuff
    }

    void DoSomethingNew()
    {
    }
}

既存のすべての顧客は引き続き古いバージョンを呼び出します。 この状況は問題ありませんが、お客様は新しいバージョンの利点を利用できません。 クラスに対してコードを作成したユーザーは、 SysObsolete 属性引数で指定したメッセージと共にビルド警告を受け取ります。 おそらく、これらのクライアントは、新しいメソッドを使用するようにコードを更新します。 時間が経つにつれて、より多くのクライアントが新しいバージョンに移行します。 そのため、ある時点で、メソッドに対するコーディングをハード エラーにすることは理にかなっています。

class SomeApi
{
    [SysObsolete("Use DoSomethingNew instead", true)]
    void DoSomething()
    {
        // Do great stuff
    }

    void DoSomethingNew()
    {
    }
}

繰り返しますが、前述の理由から、古いメソッドがプライベートまたは内部にされていないため、古いメソッドを完全に取り除くことができない場合があります。

非推奨メタデータ

モデル要素 (テーブル、データ エンティティ、EDT、列挙型など) を非推奨にするには、すべてのモデル要素型で使用できる IsObsolete プロパティを使用します。 IsObsolete プロパティは、テーブル、ビュー、およびデータ エンティティ フィールドでも使用できます。 IsObsolete を [はい] に設定すると、その要素またはフィールドへの参照によってコンパイル警告が発生します。