自分では、私はかなり怠け者のプログラマーです。 これがおそらく、中小企業の幅広いタスクを解決するのに適したツールを作成するというアイデアに長い間悩まされていた理由です。 これは、企業情報システムのアーキテクチャテンプレートがどのように表示されたかを示したもので、最初にCMS / CMF
OpenKit.netの形式でエンタープライズWebプラットフォームの開発に適用しました。
自転車の発明は私のお気に入りの娯楽ではありません。 さらに、ほとんどの新しいソフトウェア技術は半世紀前のアイデアに基づいているという事実を知っています。 したがって、私の夢の実現について初めて考えて、私は本屋に向かい、古典の一つを手に入れたいと思った。
最初はBertrand Meyerの著書「ソフトウェアシステムのオブジェクト指向設計」（1000ページという重いレンガですが、今は誰が簡単ですか？）です。 私が読んだように、これがまさに私が必要とするものであるという感覚が強まった。 想像してみてください。簿記用のアプリケーションの作成を開始し、徐々に多くの機能を追加し、しばらくしてから見て回ると、プログラムはすでに軌道ステーションを制御することがわかっています。
もちろん、このジョークにはジョークがありますが、基本的には本当です。実際のシステムには主な機能がありません。 「このシステムは何をしますか？」デザイナーが尋ねるべき最後の質問です。 このことを最初に学んだのであれば、「クラス」や「オブジェクト」という言葉が本当に好きだったとしても、おそらくオブジェクト指向プログラミングとは何の関係もないでしょう。 ここにある。 私自身はそれについて読むまで知りませんでした。
私は、クラスターからシステムをコンパイルするアイデアに特に興味がありました。それを、私の理解と能力を最大限に活用してプロジェクトに変換しようとしました。 その結果、.NETの汎用性のおかげで、当初意図していたよりもさらに普遍的なシステムが得られました。 たとえば、「Net」クラスターから、1つのアーキテクチャテンプレートに従って、さまざまな種類（web、winForms、Console、Remotingサービスなど）のアプリケーションを構築した都市全体を構築できることがわかりました。
一般に、これは、古い抽象的で普及しているスキーム「コア（エンジン、シェル）+モジュール」の別のバージョンです。 残念ながら、その実装には、1つの重大な病気がしばしば発生します。それは、何らかの形でモジュールがカーネルと統合されることです。 このため、システム内の関係の数は、新しい関数の追加とともに指数関数的に増加します。 開発者が毎回変更を加えることはますます難しくなり、メンテナンスのコストは急速に増大しています。そして、必然的に開発者がかさばり、すでに超高価なシステムの制御を失う時が来ます。
これに対する唯一の解決策があります。一方ではスタンドアロンモジュールであり、もう一方ではモジュールの内容からシェルが完全に独立しています。 「モジュール=クラスター」を採用した後、前述の病気に悩まされず、広範囲に適用される企業の問題を解決するのに適したツールのバリエーションを提供します。
ソリューションは2つの部分で構成されます。
1.会社が開発したすべての異種（web、winForms、Console、Remoting Servicesなど）モジュールに共通の自律モジュールAPI ...
2.各タイプのアプリケーション（Web-独自、winForms-独自など）ごとに1つのグラフィカルシェル。これらのコンポーネントへのアクセスを提供し、このAPIを介してコンポーネントとの作業を整理します。
ソリューション
の概略図を次の図に示します。
企業情報システムとそのモジュールの提案されたアーキテクチャ。
1.アーキテクチャモジュールテンプレートグラフィカルに、モジュールの構造は次のように表すことができます。
Cluster .Net Reflectionを介してシェル（CMFなど）がモジュール（dllアセンブリ内）で検索するオープン（パブリック）抽象クラスを実装します。 このクラスからCMFは、モジュールに含まれる機能、Webファサードがあるかどうか、「Webシェルに登録できるかどうか」に基づいて「学習」します。
クラスターのタスクは、意味に関連する適用されたオブジェクトモデルを結合することです。 これは、ソフトウェアパッケージの機能を管理するための管理単位です。
Webファサード -これは、CMFがこのモジュールに含まれるWebアダプターを学習し、それを介して動作するオープンインターフェースを持つクラスです。
Webアダプタは、アプリケーションオブジェクトモデルの一部を操作するためのグラフィカルWebインターフェイスを提供するクラスです。 たとえば、記事のリストを表示します。 ASP.NETに精通している人は、別のascxファイルだけでなくアセンブリ内にあるascxコントロールと考えることができます。
同様に、winFormsのファサードとアダプターを使用できます。 この場合、アダプターはフォームクラスになり、サーバーからグラフィカルシェルに、Remotingを介してクライアントに転送し、そこで実行できます。 これを実装するアイデアは、RSDN Webサイトの7年前の記事
「多層アプリケーションでのRemotingの使用」にあります。データ構造の変更とそれに関連するグラフィカルインターフェイスの必要な変更は、異なるプログラムのコードへの介入を必要とせず、1つのアセンブリ内でのみ行われることに注意してください。
モジュールのより詳細な説明は、
プロジェクトWebサイトの開発者ガイド
にあり、ソースコードも記載されています。
2.グラフィカルシェル。シェルの主なタスクは、ユーザーがモジュールの機能にアクセスできるようにすることです。 モザイクのようなシェルに、それらが提供するグラフィカルインターフェイスが収集されます。 たとえば、Webシェル（CMF）は、HTMLインターフェイス、winForms-shell-フォームなどを使用して作業を整理します。...シェルに対するモジュールの追加/削除は、ファイルのヒープを手動で構成することなく、プログラムによって排他的に行われます。 理論的には、これはアーキテクチャの比較的単純な部分であり、原則として、適用されたオブジェクトモデルの変更による影響を受けないはずです...
このようなアーキテクチャは、企業インターフェイス、単一の認証、および展開という3つの問題を同時に解決します。 したがって、これらの問題はすべてアプリケーションモジュール（アプリケーション）から削除されるため、大幅に簡素化されます。
デプロイメントに関しては、winFormsの場合、シェルのみをクライアントマシンに配置するだけで十分です。GUIモジュールを含むすべてのアプリケーションスタッフィングはサーバー上に配置されます。 したがって、winFormsアプリケーションの展開と保守でさえ、Webアプリケーションと何の違いもありません。サーバー上の1か所でのみ変更を行う必要があり、システム管理の簡素化（コスト削減）を実現します。
最も興味深いの
は、サイト、デスクトップアプリケーション、および企業の統合ソリューションの根本的な違いが消去されることです。これらはすべて同じモジュールに基づいているためです。 そのため、たとえば、名刺サイトから始めて、徐々にシステム全体のプラットフォームに変えて、システムのアーキテクチャを変更せずに構成を拡張することが可能です。
しかし、実装中に大きな落とし穴に遭遇しました。 このようなアーキテクチャは.NETの汎用性のおかげでのみ可能ですが、あらゆる努力にもかかわらず、私はASP.NETをそれに組み込むことができませんでした。 キャッチは、一方で、ascxコントロールおよびdllアセンブリをaspxページから「引き裂く」ことができないことです。一方、それらの間に取り外し不可能なハードリンクがあります。 Web上のwinForms（ASP.NETの主なアイデア）の概念を最後まで引き出そうとする試みは、どういうわけか完了しませんでした。
この結果、CMF
OpenKit.netを設計するとき、ASP.NETテクノロジーと見なされるものが強制的に拒否されました。 これには、プラスとマイナスの両方のポイントが伴いました。 欠点は、CMFモジュールの開発者がプログラムでフレームワークに組み込まれたコントロールしか使用できないことです。 利点は、開発者がコードをコンパイルする機能を保持しながら、ASP.NET
を忘れること
を完全に忘れることができるようになったことです。
一般的に、winFormsの概念をWebに取り入れるという考えは、私にはかなり疑わしいようです。 winFormsアプリケーションでは、原則としてコンポーネントGUIなしでは実行できません。 しかし、HTML、CSS、JavaScriptを備えたWebでは...？ ごめんなさい たとえば、インターフェイスプリミティブをサーバーコントロールにフラッシュするなど、重要でない側面を単純化すると、テクノロジ全体が非常に複雑になります。 ただし、判明したように、ASP.NETの知識がなくても、.NetでWebアプリケーションを開発する場合は非常に可能です。 モジュール開発者もOpenKit管理者もASP.NETの知識をまったく必要としません。
その結果、未知の方法と未知の方法で記述された多数の異なるアプリケーションの代わりに、おそらく異なるタイプの数十のモジュールがありますが、1つの標準に従って1つの言語（JavaScriptを含まない）で記述され、1つまたは2つのグラフィカルシェルで結合された同じアーキテクチャを備えています。 メンテナンスコストは最小限に抑えられる傾向があり、企業情報システム全体が簡素化されるため、メンテナンスの信頼性とコストが低下します。
小規模な企業にとって、このソリューションはERPおよび同様のシステムの低コストの代替品になる可能性があります。 その開発者は、一方では過剰な機能や購入したソリューションの不十分な柔軟性を過剰に支払うことなく、他方では多種多様なプログラムからの「パッチワーク自動化」を回避することなく、この企業で本当に必要な機能のみを独自に作成できます。
PS怠azine：全体的なエネルギーコストの削減により多くの努力を注ぐことができる品質。 作業を容易にするプログラムを作成し、不必要な質問に答える必要がないように、作成した内容を文書化する必要があります。 （Larry Wall、Steve McConnellのPerfect Codeを引用、M。2005、p。810）