APIは極力使わない方が良い？

Question

アクセス+VBAでシステム構築しています。

ＶＢＡで色々記述しているのですが
先輩から「なるべくAPIは使わないでくれる？」と言われました。

とりあえず「わかりました」と答えましたが理由は聞けませんでした。

APIを使う事によって不都合が発生する理由は何でしょう？

開発環境は
ＷＩＮ７、アクセス２００７
ＡＤＯ・ＤＡＯを使う
シングルユーザー（共有なし）
です。

ご回答よろしくお願いします。

WindFaller · Accepted Answer

こんにちは。

ご質問者様が、おっしゃっているのは、Win32 APIの話だと思って書きますから、それが違うなら、この回答はパスしてください。APIでは、意味が広すぎます。

それで、Access で、VBAでということですね。
VBAの範疇では、可能な範囲では、使ったほうが便利だとは思います。

Access VBAですから、Win32 APIを使うということですから、ある程度、決まったものしか使わないと思います。何を使おうとして、注意が出たのかは分かりません。
それに、先輩さんの実際の意図という所は分かりません。実力の問題もあると思いますから、突っ込まなかったことが正解かもしれません。

Access もプライベートではなく、一応、開発バージョンなら、私も、なるべくそちらを優先して使うと思います。プライベートでは、VB RunTime(Access Runtimeではない） もライセンスがなかったりするから、代わりのもを使うのは、やむを得ないのです。経験的には、OSが変わると影響が出るような気がしますが、ハングの原因は、今のところ掴めません。信頼性の問題で疑われやすいということだけです。しかし、100%使わないということは、初心者ならともかく、それはできません。

移植性については、Win32 APIの64bitの移植は可能なそうですが、本家のMSが今盛んに、.Net Frameworkへの転換を主張していますから、一応、プライベートの使用以外には、Win32 APIを減らしていく方向でないといけません。しかし、かと言って、.Net Frameworkが、VBAで使用出来る範囲はとても限られている、というところが現状ではないかと思います。今、端境期なのか、ものすごく中途半端な状態だと思います。

私自身は、MS OfficeのVBAの場合は、Win32 APIの安全な使用可能の境界線が見えないのです。VB6の時のように、ほとんどフルレンジで使用可能ではないのです。そこがネックなのです。

自分で書く分には問題は少ないのですが、コーディング・チェックする側になると、これは、構造体を含めミスされると、どうしようもなく混乱してきますね。さっぱり流れが読めなくなるのです。（自分で書いていて、笑ってしまいます。それ、「難癖やないか～。あんたが実力ないからやないか～。」と。でもね、一般のコードは、すぐにミスは分かるのですが、VB系では、Win32 APIは、ツールを使って書くものだから、ツールを使わないで書いたものは、信用できないのです。本当は、VB/VBAユーザーには、ネガティブ・リーズンはもう少しあるのですが、いい加減にしておきます。）

gungnir7 · Answer

そもそもADOやDAOがAPIなのですが、これは質問の意図からして違うのですよね。
declareステートメントを伴ったAPIの活用が時代遅れのものだということです。

不都合は.NetFrameworkの範囲内で対処できないというところでしょう。
例えば32bitと64bitでは動作が違ってきます。
OSの仕様を突然変えられると、将来的なメンテナンスを余儀なくされる可能性もあります。

ok-kaneto · Answer

人によって主義主張が異なりますから、一般論を。

・移植性に欠ける
32bit→64bitの他、OSのバージョンに依存する可能性

・可読性に欠ける

・インタフェースにバグがあればアプリがこける可能性

かなあ。

notnot · Answer

特に不都合は無いでしょう。そう言った人に聞かないと無理です。

APIは極力使わない方が良い？

こんにちは。

そもそもADOやDAOがAPIなのですが、これは質問の意図からして違うのですよね。

人によって主義主張が異なりますから、一般論を。

特に不都合は無いでしょう。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング