1

最近、古い Access Forms アプリケーションを更新するように依頼されました。私は .NET のバックグラウンドを持っていたので、この変更は恐ろしく、やや不快になりました。私はこれらがレガシーテクノロジーであり、急速に時代錯誤になっていると思っていました...

私が間違っている？もしそうなら、この技術を使い続ける理由は何ですか?

4

4 に答える 4

28

質問のサブテキスト (つまり、Access アプリは何があってもひどいものであるということ) に答える代わりに、Access の将来についていくつかの情報を提供します。

  1. Access は Microsoft の主力製品です。Microsoft の製品ラインにはこれに代わるものがないため、近い将来、何らかの形で Microsoft によって引き続き宣伝および開発される予定です (MS の Office スイートがある限り、Access も存在します)。

  2. Access が提供する機能について、MS 以外との競合はほとんどありません。同等の製品は FileMaker Pro だけです。OpenOffice スイートの Base コンポーネントは競合的であると言えるかもしれませんが、それは FM と Access によって提供される機能のサブセットのみをカバーしています (これは、多くのシナリオに対して十分ではないということではありません)。

  3. Access (および Office スイート全体) は依然として VBA をプログラミング言語として使用しており、残りの Microsoft は VB から .NET ベースの言語に移行しています。他の Office 製品は .NET コンポーネントを使用できるようになりました (ただし、VBA を使用する方法とは異なります) が、Access の場合はそうではありません。Access の次の 2 つのバージョン ( A2010 ではない) で、何らかの形で .NET サポートが導入されることを期待しています。しかし、MS の歴史を知ると、VBA はいくつかのバージョンで引き続きサポートされます。

  4. Access アプリケーションは、歴史的に、FileMaker が何年も前に提供した Web 展開に関して大きな弱点を持っていました。A2010 は、Access クライアントと Web ブラウザー (標準に準拠した任意の Web ブラウザー) でまったく同じように実行できる新しい Web オブジェクトを使用して Access アプリを作成できるようにする SharePoint 統合によって、その大きな時間を修正します。 IE)。

  5. Jet データベース エンジンは、Jet 4 のリリース (1999 年) の前後に、MS によって基本的に終了したと宣言されました。ただし、MS は Jet 4 を Windows オペレーティング システムのコンポーネントにしました (現在もそうです)。Jet は、Access 2007 のリリースと、Access 開発チームが所有する ACE と呼ばれる新しいバージョンの Jet データベース エンジンを組み込むことで新たな命を吹き込まれました (Jet 4 は引き続き Windows 開発チームが所有し、現状のまま凍結されています)。 、追加の開発なし)。ACE に導入された新機能の多くは、Access を SharePoint と統合するという Microsoft の目標によって推進されていますが、A2010 では、一部の新機能 (トリガーと同等の機能を有効にするテーブル レベル データ マクロなど) は、Microsoft Access がなくても非常に役立ちます。 Sharepoint を使用します (複数値フィールドなどの他のものは使用できません)。64 ビット バージョンの Office では、

さて、最後の質問です。

@ChrisDiRulliが尋ねました：

このテクノロジーを使い続ける理由はありますか (移動コストを回避する以外に)?

もちろん、Access を使い続けるのには十分な理由があります。

  1. アプリはすでに開発されています。

  2. アプリが機能するか、仕事を完了するのに十分に機能します。

  3. アプリは、完全な書き直しではなく、いくつかの新機能のみを必要とします。

  4. アプリは、展開の問題がないユーザーのグループによって使用されます (すべてのユーザーが完全なアクセス権を持っているか、ランタイムを使用しています)。

Access には素晴らしい未来があるように思えます。Office スイートに VBA を導入し、Office スイートの上に構築された「メタアプリケーション」の作成を可能にした Office 95/97 のリリース以来、私は Access についてこれほど熱心ではありませんでした。

特定の状況では、従来の Access アプリでは、既存のアプリを修正する方法を誰も知らない、または既存のアプリがスパゲッティ コードとマクロの混乱であることが問題になる可能性があります (マクロを使用している場合は、それらがどのように相互関係しているかを伝えることはほとんど不可能です)、またはスキーマが悪い、または、または....

問題が、アプリを救出するための才能 (または興味) を持っていないということである場合は、経験豊富な Access 開発者である請負業者を雇うことを検討する必要があります。それらの人々を見つけることはそれほど簡単ではありませんが、そこにはたくさんの人がいます. 誰が有能な人かは、Access Usenet グループの公開投稿や、ここ SO の一部でさえ知ることができます。

それをしたくない場合は、Access アプリを修正する方法を見つけようとするか、Access の外部で同じ機能を複製するのにどれだけの費用がかかるかを発見するために、より多くのお金を費やす可能性があります。後者の場合、多くの組織はアプリを同じ機能の一部しか提供しないアプリに置き換えることを選択します。これは、エンド ユーザーを遠ざけ、予約を取りやめ、将来 IT 部門に助けを求めないように促すための優れた方法であるため、おそらくお勧めできません。

しかし、まず最初に：

アクセスへの敵意を失います。それは不合理であり、完全に無知に基づいている可能性が 99.99% あります。

于 2010-02-12T18:23:24.463 に答える
9

COBOL で書かれたソフトウェアはまだたくさんありますが、それは Access よりもずっと古いものです。

Access アプリケーションでおそらく十分であり、最も安価なオプションである領域がいくつかあります。それが仕事を成し遂げるなら（あなたの仕事の一部は、それが本当に仕事を成し遂げるかどうかをあなたの雇用主に知らせることです）そしてそれが彼らが望むものであるなら、それを求めてください.

.NET プロジェクトの方が優れている、または Access が不十分であるという正当な理由がある場合は、それらについて率直に話し合い、小切手を切る人の最善の利益となる決定に達するようにしてください。

于 2010-02-12T17:21:46.663 に答える
4

機能するため、保持します。ビジネスのニーズが大きくなりすぎて、Access アプリでは仕事を完了できなくなった場合 (ビジネスにとっては非常に良いことですが、Access 開発者がこの分野の知識を欠いている可能性があるという不幸な兆候です)、できることや、できる人を雇う。

あなたは、すべての開発者が経験することに不満を感じていました。「 &^% &、新しいアプリケーションを構築しなければならない! 3 年前の .NET コードに戻って修正するのはいつになるのだろうか...」と考えて 1 日を始めることは決してありません。 .

現在、Access で利用できるようにしたい .NET 機能が多数あり、2010 バージョンを楽しみにしています。

于 2010-02-12T18:28:03.703 に答える
3

適切な仕事には適切なツールを使用してください。IT 部門の多くの人々は、Excel から抜け出したばかりの誰かによって作成されたひどいひどいデータベースを維持しなければならないことから、アクセスを延期しています。ただし、アクセスには多くのことが必要です。たとえば、短いターンアラウンド タイムで約 10 人のユーザーに迅速にロールアウトする必要があるプロジェクトが近づいています。この仕事のために、私は SQL サーバーと Visual Studio のコピーをシェルフに残し、アクセスを使用しています。アクセスが仕事に合っているのなら、.net にできるように .net で書き直す必要はありません。私にとって、使用するプログラミング ツールは目的を達成するための手段であり、機能ではありません

于 2010-02-12T22:32:23.270 に答える