7
大規模な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ライブラリを実装したことについて言及するのを忘れましたが、問題はここでもコールバックの欠如でした。マルチスレッド化は、本当に良い解決策ではありませんでした。