私たちはアプリケーションをVB.Net 2008からClassic VBに移行しており、ベース名前空間とビジネスレイヤーを作成する必要があります。私のアプローチの方法は、私たちのトップのBAを訪問し、私たち（債券）会社の共通領域を特定し、可能な限り多くのコードをジェネリックで作成することです。企業の.Net名前空間フレームワークを最初から作成するアプローチにはどのような方法がありますか？
Web FocusをOLAP側に取り入れることを検討しています。これは企業ネームスペースのデザインとそのデリバティブにどのように影響しますか？
コーポレート.NETフレームワークの作成を開始する最善の方法は、現在の企業プロジェクトから既存のコードを取得することから始めることです。具体的で具体的なプロジェクトのコードを書かずにBAと話し合ってフレームワークを構築すると、一部の領域でフレームワークを設計しすぎる可能性があり、他の部分で必要な機能が完全に失われる可能性があります（フレームワーククライアントには正当な理由がありません）。
さらに詳しい説明は、Harvested FrameworkのFowlerのエントリとblog postを参照してください。
私はWeb Focusに精通していませんが、それは何らかの形で影響を与えるだろうと推測していますが、Harvested Frameworkを使用すると、構築した最初の数種類のアプリケーションで使用すると、フレームワーク内でWeb Focusを使用します。
Jeremeはフレームワーク上で正しくあります。名前空間について明白なことについて簡単に触れる。
名前空間が何であるかを常に覚えておいてください。名前空間が存在する「スペース」を提供することです。特に、そのスペース内に名前を作成する人々が、重複したり混乱した名前をつくる可能性が低いほど小さいスペースを提供することを意図しています。
これは、名前空間が組織のパターンまたはドメイン知識に沿って編成されている場合にのみ機能します。よく使用される簡単な例は、会社のパターンです。 ビジネスユニット。 アプリケーション。この理論は、特定のアプリケーションに取り組んでいる開発者の中には、名前の重複の可能性が少ないという理論があります。大規模なアプリケーションでは、レイヤーや領域に基づいてさらに分割する必要があります。同様に、ビジネスユニットの大きさが大きすぎる場合は、それを打破したいと考えています。
しかし、すべての場合、名前を作成する頭脳のように、脳のセットを実際に分割しようとしています。
アプリケーションがVB6（VB3ではなく）の場合は、まずVB6のクラス階層を再設計することを強くお勧めします。その理由は、どのような変換においても、古いアプリケーションの動作を維持しようとするためです。これを行うためのプロジェクト時間を延ばし、同時にデザインを変更します。
最初にアプリケーションのオリジナル言語の設計を変更すると、その結果生じるバグは変換ではなくデザインによるものであることが保証されます。
私は過去20年間で私たちのソフトウェアの3つの主要な変換を行いました。 （DOSからVB3へ）（VB3ではVB6でオブジェクト指向設計に）、（VB6からVB.NETに）。
最後に、VB.NETのポートがすぐにVB6で設計するのは簡単です。トリックは、特定のVB6のAPIとインターフェイス（グラフィックス、印刷など）の背後に構築を非表示にする>
私は変換を行うときは、上から下に作業することをお勧めします。フォームをまずVB6 COM DLLを呼び出す.NETに変更します。下のDLLに到達するまで各層を変換します。
また、デザインを変更して複雑なアプリケーションの別の言語に変換しようとすると、変換時間が2倍になります。
これはVB6なので、VB6タグです。 現在のシステムをインポートする必要はありません。障害があり、私たちのニーズは設計時から変更されています。また、既存のアプリケーションには、新しい継承ベースのモデルでは望まないコードの複製がたくさんあります。 – MaSuGaNa
私たちには、ほとんどのアプリケーションで使用されているギルト・インストゥルメントなど、多くの一般的なビジネス・オブジェクトがあります.MatLabに現在複製されている数学ベースの処理も多数あります。これも組み込む必要があります。収穫されたフレームワークはうまくいくとは思うが、段階的なイン/アウトインターフェイスを使っているかもしれない構造の多くを保存する必要があるとも思う。 Web FocusはBizTalk .Netのツールセットを使用していますが、2008年のバージョンはまだベータ版です。 – MaSuGaNa