大規模なMS Accessアプリケーションを.Netに移行するためのベストプラクティスは？

最初は個人的なニーズに合わせて社内で開発された非常に巨大なMS Accessアプリケーションがあり、その後商用ソフトウェアに変換されて販売に成功しました。ソフトウェアは一種の「万能ソフトウェア」であり、ドキュメント管理システム、エンタープライズリソースプランニング、在庫管理、顧客関係管理、データ分析などのいくつかのモジュールが含まれています。アプリケーションの機能ですが、クライアントからのリクエストに応えるためには、新しいものに移行する必要があることに気付きます。

Visual Basic .Netに固執できるため、アプリケーションを徐々に.Netに移行することにしました。ここではほとんどの開発者にとって新しい言語ですが、VBAおよびVB6で実装された数十の小さなプロジェクトに関する深い知識があります。

すべてのデータ操作と検索がサーバー上で直接実行されるように、すでにアプリケーションのデータレイヤー機能をMS SQL Serverに移行し始めています。

私たちが探しているのは、拡張GUIを徐々に移動するためのベストプラクティスです（サブフォームを含む約500〜600の異なるフォーム、多言語サポートのある約200のレポートなど）。潜在的な顧客からDMSのドキュメントに非同期データ暗号化を実装するという最近の要求に従って、この部分をMS Accessから完全に切り離し、.Netで実装することもできます。

問題は、.Netアプリケーションを既存のMS Accessシステムとシームレスに統合し、特定のパラメーター（ユーザー権限など）で呼び出すことができ、このアプリケーションと実行中のMS Accessアプリケーション間のデータ交換を可能にする方法です。

編集：

マーティンファウラーの著書「エンタープライズ統合パターン」にあるいくつかのプラクティスを適用して、MS Accessアプリケーションと、さまざまなニーズに合わせて.Netで実装したいくつかの小さなユーティリティを統合しようとしました。しかし、なんとか「共有データベース」パターンを使用することができただけであり、ソリューションに本当に満足していませんでした。

たとえば、POP3接続を使用してメールサーバーからすべてのメッセージを自動的にダウンロードして1つのテーブルに保存するWindowsサービスとして実行される小さなユーティリティを実装しましたが、すべての添付ファイルはファイルシステムに保存されます。

主に行ったのは、ADO.NETを使用してMDB形式のMS Accessデータベースに直接アクセスし、処理済みのデータ（上記の例のメールメッセージに関するデータなど：FROM、TO、CC、BCC、件名と本文）。

.NetのMDBデータ形式を使用してもまったく問題はありません。さらに、MDBにとどまり、ほとんどすべてをMS SQL Server 2008にアップサイズすることは望ましくありません。これにより、データ管理とスケーラビリティに関する自由度が高まります。

ここでの主な問題は、データの更新時に特定のVBAコードの実行をトリガーできるように、Accessで一種の「コールバック」を実装する方法がわからないことです。

データテーブルの更新および挿入トリガーをサポートする MS Access 2010には大きな期待がありましたが、これらのトリガーにはMS Accessマクロしか使用できず、トリガー内でカスタムVBAコードを実行する方法はありませんでした。

また、ユーザーが呼び出したデータの再クエリを模倣するために、キーストロークをMS Accessウィンドウに直接送信するソリューションもいくつか試しました。これは機能しますが、本番環境で使用できる現実的なソリューションであるとは考えていません。

MS AccessのDDEも検討しましたが、DDEコマンドを実装し、それらをインメモリデータおよびコマンド交換に使用する優れたサンプルソリューションは見つかりませんでした。

そのため、主な問題は、MS Accessと.Netアプリケーションを共存させて相互作用させることです。

EDIT2：

.NetとMS Accessの間でメッセージを渡すためにVBAにMSMQライブラリを実装したことについて言及するのを忘れましたが、問題はここでもコールバックの欠如でした。マルチスレッド化は、本当に良い解決策ではありませんでした。

これは大規模で非常に複雑なプロジェクトになります。私は何度もAccessデータベースを.NETに移行する責任がありましたが、この規模ではありません。段階的なアプローチがおそらく最も現実的であることに同意します。ワンショットですべてを引き受けることは、失敗する簡単な方法です。

他の回答と同様に、最初の最も重要なステップは、すべてをSQL Serverに移動することです。これを行っている間に、これがまだ行われていない場合はデータベースを文書化し、存在する場合はリファクタリングの領域を特定します。進化するニーズに合わせて成長するAccessデータベースには、多くの場合、全体像を見るときに改善できるデータモデルがあります。

次に、「自己完結型」であるアプリケーションのモジュールを特定します。これはあらゆることを行うデータベースであるため、相互にほぼ完全に切り離されたモジュールがおそらく存在します。これらのばらばらのピースを用意した後、更新されることから最も利益を得ることができる小さなモジュールの1つを特定し、最初にそれを引き受けます。

.NETへの移行中に、アプリケーションの単純な1対1のコピーを実行しないでください。ユーザーからの入力を収集して、現在のアプリケーションの問題点を特定します。最初の移行ユニットが大成功を収め、他のすべての人から完全な賛同を得ることを望んでいます。

最初のユニットを完了したら、課題、困難などの点で何が起こったのかを見て、これを前進させてください。

私が強く推奨しないことの1つは、部分的に機能するモジュールを実装することです（例：「CRMを移行しましたが、機能X、Y、Zはまだ新しいシステムにありません」）。これにより、ユーザーは、古いシステムが「完全に正常」だったときに、不完全なシステムを持つことですぐにイライラします。この種の開発は、他のドメインでは問題なく動作しますが、ユーザーが古いAccessモノリスに「何も問題がない」と感じ、移行のニーズを理解していないビジネスでは機能しません。

突然変異によってMS AccessアプリケーションをVB.Netアプリケーションに変えるための一種の計画があります。

これは一般的な計画ではなく、次の計画は説明したプロジェクトによって異なります。

ステップ1：すべてのデータをSQL Serverに移行する

SQL Serverへの接続アクセスにODBCを使用せず、代わりにAccess Project（ADP）を使用します。Accessプロジェクトは、拡張子が.adpのAccessファイルであり、完全なAccess機能（マクロ、フォーム、レポート、モジュール）を備えていますが、MDBファイルではなくSQL Serverデータベースに直接接続されています。ADPファイルはMDBファイルと非常に互換性があります。Access 2010ではサポートされていないようです。実際、この機能は非表示になっていますが、非常によくサポートされています。MDEと同様に、ADPファイルはADEファイルに「コンパイル」できます。

SQL Serverへの移行には、データ構造とコードの変更はほとんど必要ありませんが、すべての移行は非常に簡単です。そして、それは結局のところ最終的な目標です。

VBAまたはVB.Netコードへのデータベースイベントのトリガーを忘れてください。これは技術的にはSQL Server拡張ストアドプロシージャを使用して実行できますが、非常に悪いトリックです。プロジェクトには将来の生命があります。そのため、このような種類の破壊的な橋を避けることにより、データ構造を強化することをお勧めします。一般に、データベーストリガーを試してみてください。スマートですが、メンテナンスが非常に困難です。

ステップ2：認証を統一する

アプリケーションがAccessセキュリティ（MDWファイル）に基づいていないことは良いことです。

VB.Netアプリケーションのターゲット認証の計画を立ててから、2つのアプリケーション間で統一認証を行うために、このターゲットにアクセス認証を移行する方法を定義します。

アプリケーションアーキテクチャでは認証が横断的であるため、AccessバージョンとVB.Netバージョンを簡単に切り分けることができます。

ステップ3：AccessとVB.Netの間の橋渡しをするためにトークン機能を準備する

あなたは言った、アクセスUIは、いくつかの正確なパラメーターと認証でVB.Net UIを開く必要があります。そして、おそらく他の方法でも同じことをしなければならないでしょう。

良い解決策は、トークンテーブルに基づいて小さなトークン機能を構築することです。列には、トークンID（整数）、トークンキー（長い文字列）、トークン日付、およびパラメーターリスト（長い文字列またはテキスト）を指定できます。AccessがVB.Net画面を開く必要があるたびに、パラメーターを使用してデータベースにトークンを保存し、トークンIDとトークンキーのみを使用してVB.Netアプリケーションを開きます。VB.Netが開き、データベースでトークンIDを検索し、キーを確認し（これは認証として適用されます）、パラメーターを読み取ります。次に、対応するフォームを開き、必要なことを行います。トークンに期間を指定し、古いトークンを消去することを忘れないでください。

VB.NetからAccessにコールバックする必要がある場合（おそらくそうです）、OLEを使用して、開いているMDB AccessファイルでいくつかのVBAコードをアクティブにすることが可能だと思います。

ステップ4：画面ごとのUIおよびモジュールの画面、モジュールごとのモジュールの移行

これで準備の大部分が完了しました。Ms AccessからVB.Netへのユーザーインターフェイスの移行を開始できます。

これを行うための適切な自動ツールはありません。VBAと.Netはあまりにも異なっています。このような移行のために作業を準備する必要があります。「About」ボックスのような小さなフォームから始め、単純なフォームから複雑なフォームに進みます。もちろん、いくつかの移行をバンドルしてスケジュールする必要がありますが、画面、レポート、ライブラリをMs AccessからVB.Netに徐々に移行します。

Accessを使用してすべてを行ったことに驚かされます。.NET Windows Formsまたは.NET WPFを問わない非常に重要な質問があります。WPFの学習曲線は急勾配ですが、私の意見では、より優れたUIを備えているため、より強力です。最近、商用アプリケーションをFormsからWPFに変換し、すでに売り上げを伸ばしています。新しい機能も追加しましたが、WPF UIはよりセクシーです。テーブルデザインを確認して、クリーンアップします。今がその時です。すべてのFKを宣言していることを確認してください。Accessでは、アイテムがスリップすることがあるので、その場で簡単にアイテムを追加できます。これが初めてのWPF UIである場合、いくつかのプロトタイプを作成します。新しいアプリがより多くの機能を備え、画面が少なく、コードがはるかに少ないという点で、WPFにより多くを詰め込むことができます。XAMLを嫌うことから、それをどれほど愛することになるでしょう。MVVMのような構造を考えてください。

既にAccessオブジェクトモデルをよく理解しているので、.NETアプリからAccess Interopを使用したいと思うでしょう。DDEを不透明にすることなく、（多かれ少なかれ）Accessアプリの制御を自動化できるはずです。

ビジネスロジックレイヤーに関する深い知識はありませんが、.NETアプリケーションでMS Accessデータベースにアクセスすることもできます。データの取得だけではない場合は、プログラム（VB6およびVB.NETアプリケーション）間にTCP / IP接続を実装できます。CodeProjectの記事をご覧ください。

あなたは間違ったことをする方法についてのベストプラクティスを求めています。ありません。ベストプラクティスには、保守可能なシステムを効果的に作成する方法が含まれているため、バスがクラッシュし、まったく新しいチームが寒くなる必要がある場合でも、開発とサポートを継続できます。あなたが説明するシステムは、丘のために走っているほとんどの開発者を送ります。時代遅れの技術で構築された製品があり、今日の技術とのインターフェースを取りたいと考えています。そして、あなたはコア製品について説明したアンチパターンのいずれにも対処せずにそうすることを望みます。取り組む意志のある開発者は、あなたが提案する条件でそうすることを望まないでしょう。

ただし、バスはクラッシュしていないため、システムを理解している既存のチームを活用できます。私が見つけた段階的な開発の最良の方法は、アジャイル手法を使用することです。高いリスク要件に早期に対応し、ビジネスニーズに適切に対応する反復プロセスをサポートします。

アプリケーションを徐々に.Netに移行することにしました

しばしば間違い。ベストプラクティスは、「徐々に」試行しないことです。

ここではほとんどの開発者にとって新しい言語ですが、VBAとVB6に実装されている数十の小さなプロジェクトに関する深い知識があります。

決定のための非常に良い根拠ではありません。新しい言語を学習したい場合は、VBを学習しないでください。C＃またはJavaのような優れたものを学んでください。

「ここにいるほとんどの開発者にとっての新しい言語であり、VBAの深い知識を持っている」は、「私たちにはいらいらしたくないVBAの達人がいます」という一般的なコードフレーズです。それはおそらく悪いことでもあります。

探しているのは、大規模なGUIを徐々に移動するためのベストプラクティスです

ベストプラクティスには「段階的」は含まれません。それらには「完全に破棄」が含まれます。

私が見た段階的な移行は、とても難しいので壊れています。

これを行う方が良いでしょう。

1. 最も貴重な資産を保存します。データ。すべてのデータをSQL Serverに移動します。それのすべて。すべてのMS-Accessを書き換えて、SQL ServerへのODBC接続を使用します。たった今。

2. MS-Accessで一時テーブルやデータなどを作成した人を解雇します。すべてのデータは、MS-Accessの外部のデータベースに存在する必要があります。MS-Accessのデータが問題の原因であるため、すぐに停止し、全員が同意することを確認してください。彼らが同意しない場合は、MS-Accessを削除しようとしている間にMS-Accessでのハッキングを伴わない新しい仕事を見つけてください。

3. 現在のレポートに近いレポートを自動的に生成するレポートフレームワークを見つけます。プログラミングなし。テーブルやビューを与えて、強打してください！終わった。

4. 500件すべてのレポートを列挙します。それらをツールで簡単に作成できるレポートと、より困難なレポートに分割します。ハードレポートを「必須」、「必須」、「可能」、「後まで実行しない」に優先順位付けする。

   私の経験では、データベースビューは多くの場合20ほどのレポートで再利用されます。そのことから、500件のレポートの派生元となる25の関連ビューがあると思います。レポートの生成を自動化できるツールは、適切に作成された少数のSQLビューからほとんどのレポートを処理する必要があります。いくつかのレポートは、自動化ツールとしては複雑すぎるか困難です。

5. CRUDトランザクションを自動的に構築する開発フレームワークを見つけます。

6. 200のフォームをCRUDフォーム（自動的に構築可能）と非CRUDフォームに分割します。非CRUDのうち、MoSCoW（Must、Should、Could、Wo n't）ルールを使用して優先順位を付けます。

   多くの場合、アプリケーションフォームの60〜80％は、単純な自動CRUDフォームです。20〜40％はより複雑で、より熟練したプログラミングが必要です。これに基づいて、120〜160のCRUDフォームがあり、それらを書き換える必要はなく、自動化するだけです。40〜80の非常に複雑なトランザクションがあります。

7. CRUDフォームと必須の非CRUDフォームを作成します。

8. ギャップを評価します。「優先」リストの最も重要な部分に優先順位を付け直して作業を開始します。

Accessを完全に破棄するのがおそらく最も簡単です。漸進主義を避けます。

あなたは最終的にすべてのお金を使うつもりです。

あなたもそれのために予算を立てて、今それを使うかもしれません。

共存を管理しようとすると複雑になるため、これを徐々に実行しようとすると、実際にはより費用がかかる場合があります。