まず、明確にするために、私は LINQ to SPRocs について話しているわけではありません。
100 を超えるストアド プロシージャを使用する既存の DAL があります。これは、このプログラムが Web アプリであったときに作成されました。現在は、ローカル データベースを使用する接続環境での winform アプリです。時間の関係で既存の DAL を残しましたが、現在見つけています。
私の質問は、既存の DAL をそのままにして、プログラムに dbml(datacontext) を作成する際に知っておくべき落とし穴はありますか?
これにより、既存の DAL を少しずつ置き換えることができます。
SProcs の 1 つが、LINQ DataContext が現在使用しているオブジェクトのデータを変更する場合に注意する必要がある潜在的な落とし穴があります。
オプティミスティック コンカレンシー ロックが設定されている場合、最悪の場合、LINQ エンティティを後で更新できません (データベース内の基になる値が背後で変更されたため)。
これは実際には大きな問題ではありません - とにかくこれに対処する必要があります (複数のユーザー間での同時実行)。それ以外には問題は見られません。
マルク
私が知っているものはありません。DataContext は単なる別のアプリケーションと考えることができます。アプリケーションの動作が適切であれば、データベースは任意のアプリケーション接続を処理できると想定されます。Linq to SQL は、バックグラウンドで標準の SQL コマンドを使用して作業を実行し、レコード ロックやトランザクションなどの一般的なことを認識します。あなたのアプローチは健全だと思います。