この記事には理論のみが含まれています。 次の記事は実用的です（代替を試みます）。
階層化された抽象化
マルチレベルの抽象化-各レベルで抽象化が一貫するように、アプリケーションコンポーネントをいくつかの抽象化レベルに分割します。 これは少し不合理に聞こえるかもしれません。 要点は、コンポーネントをいくつかのレベルに分割することです。そのため、このレベルの抽象化を比較的自律的に行い、他のレベルに関する情報を意識することはありません。
なぜ抽象化のレベルに分かれているのですか？
1.複雑性との戦い。 各レベルで、この特定のレベルのメソッドが適用されます。
2.接続の減少。
3.トップを除くすべてのレベルでクラスの互換性を確保します。
マルチレベルのデータ抽象化
抽象化の降順で進みます。
*現実世界のエッセンスクラス
*データプロバイダー
*実際のデータライブラリ
例：
* ユーザー
* IUserProvider 、 SqlUserProvider 、 XmlUserProvider 、...
* SqlClient 、 XmlDocument 、...
同時に、接続性が低下します。ユーザーはIUserProviderインターフェイスを知っており、 SqlUserProviderおよびXmlUserProviderはIUserProviderを実行し、 SqlClientおよびXmlDocumentライブラリを使用します。 さらに、特定の抽象化レベルのオブジェクトは、次の（より低い）抽象化レベルのオブジェクトでのみ機能しますが、その逆はできません。循環接続は許可されません。
問題はいつ発生しますか？
1.通常、1つのプロジェクトにいくつかのマルチレベル抽象モデルがあります。 複数の抽象モデルが均一に変更される必要がある場合、問題が発生します。 この場合、上位レベルを含むすべての中間レベルの抽象化を変更する必要があります。
2.プロトタイプを作成する場合、マルチレベル抽象モデルの設計のオーバーヘッドが高すぎる可能性があり、抽象レベルなしで一時コードを書くことが可能です。これは、プロトタイプの承認後に破棄する必要があります。
3.データソースからの抽象化は、データソースで最適でない作業を生成する可能性があります（場合によっては生成します）。
どうする
多くの場合のコード生成（常にではない）は、マルチレベルの抽象化を置き換えることができます。 この場合、選択したデータソースを操作するメソッドを含む最終クラスが（抽象化の最上位から）生成されます。
1.メタデータに基づいて、コード生成アルゴリズムを変更し、モデル全体を一度に変更できます。
2.メタデータが利用可能な場合、できるだけ早くプロトタイプモデルを取得できます。
3.各データソースのジェネレーターが利用できるため、選択されたデータソースで、その特異性を考慮した許容可能な最適な作業でモデルが生成されます。
コード生成が複雑なモデルでどのように役立つか
複雑なアプリケーションは常に多くの質問をします。 私の観察によれば、それらのほとんどは開発プロセス中でも答えることができます（たとえば、サイトでキャッシュが必要かどうか、サーバーにどのオペレーティングシステムが必要か、出力バッファリングを使用するかどうかなど）。 これらの質問に前もって答えれば、プログラムの不必要な複雑さ、不必要なアクション、不必要なチェックなどを避けることができます。 さらに、コードジェネレーター自体は、パフォーマンスを最適化するために使用できる宛先環境でいくつかのデータを事前に収集できます。
しかし、これは結果のコードが少ない=より単純なシステムであることを意味しません。 高品質のコードを生成するには、コードジェネレーター自体の品質が十分に高い必要があります。
コード生成+階層化抽象モデル
これらのアプローチは互いに矛盾せず、一緒に使用できます。 たとえば、ASP.NETには、プロファイル（プロファイル）に個人ユーザーデータを格納するシステムがあります。 いくつかの抽象化レベルを持つ抽象モデルがそこに構築され、その上にProfileBaseがあります。 構成でプロパティのリストを設定すると、 ProfileBaseクラスの子孫であるProfileCommonが生成されます。これには、構成で指定したプロパティが含まれます。 実際、構成でメタデータを指定しました。
次の記事では、特定の単純なコードジェネレーターを開発します。