誰かが SAP Business One で EntityFramework を使用しているかどうか知りたいですか? はいの場合、保証をどのように処理しますか。SAP は、DI サーバー API を介した挿入/更新/削除のみを許可しています。そうしないと、保証が失われます。したがって、選択のみが許可されている場合、データの読み取りにはEntity Frameworkのみを使用できますが、それは正しいですか?
とにかく、SAP Business One で EntityFramework を使用することをお勧めしますか、それとも大量のデータでパフォーマンスの問題がありますか?
ご挨拶。
DI 以外のものを使用して、SAP Business One データベースからデータを挿入、更新、または削除することは絶対にできません。過去 9 年間、パートナーとして SAP と協力してきた者としての私の率直なアドバイスは、SAP を試すことさえしないということです。データベースを壊すとすぐに、SAP はそれをサポートしなくなり、それを修正するために誰かに多額のお金を払うことになります...
保証の問題は別として、SBO での最も単純な操作 (たとえば、1 行の請求書を 1 つ追加するなど) でさえ、少なくとも 10 または 11 の「メジャー」テーブルとそれに関連する「マイナー」テーブルのセットを含むオブジェクト モデルの更新が発生します。 ....SQL プロファイラーを起動し、SBO クライアントで請求書を作成し、挿入だけでなく選択も含めて生成される SQL の量を監視します....さらに、SAP がこれらすべてに対して行っていることのビジネス ロジックデータは発信者から完全に隠されています。チャンスはほとんどありません。つまり、これを自分で正しくモデル化するチャンスはゼロです....
EF を使用してデータベースからデータを読み取ることに関しては、ここでも気にしません。SAP クライアントで表示されるデータの多くは、正しく定義された関係によって取り出されないため、モデルが完全に正しくなることはありません。単純な古い SQL にうんざりしている方がよいでしょう。必ず、このデータを独自のメモリ内モデルにマップできます。
この点で、SQL プロファイラはあなたの味方です。SBO がどのように動作するかを 100% 正確に知ることはできませんが、クライアントで操作を実行し、結果のクエリを監視することで、少なくとも SBO が使用するのと同じデータにアクセスできるようになります。
また、1 つの点を修正するだけです。これを行うには2 つの方法があります。1 つは XML ベースのサービスである DI サーバーで、もう 1 つは、プロジェクトとリンクできる COM ベースのライブラリである DIAPI 経由であり、よりオブジェクト指向の方法で作業できます (確かに、非常に「オブジェクト指向」の限られた価値!)
EF を使用して SAP テーブルからデータを読み取らないという以前のアドバイスに関して、特にEF コア クエリ タイプを使用して、さまざまなテーブルに対してビューを作成することで、より簡単にデータを読み取ることができるようになりました。アプリケーションが必要とするデータ。これの大きな利点は、SBO から複数のテーブルを結合し、列名などをクリーンアップできることです。ビューは読み取り専用であり、安全に使用できます。