3

アドバイスをいただきたいです。

現在、C#、バインディング、ADO.Net Entity Framework、ODP.net、および Oracle データベースを使用して小さな WPF クライアント アプリケーションを開発しています。

アプリケーションは小さなもので、2 つの XAML 画面、約 15 のテーブルです。アプリケーションを介してエンティティに入力し、SaveChanges メソッドを使用して、エンティティを使用して開発していました。

しかし、私たちの DBA は、私には直接アクセスする権利はなく、ストアド プロシージャを使用するしかないと言いました。理由を尋ねたところ、ストアド プロシージャを使用すると、1 つのテーブルのレコードを削除するときに行識別子を強制的に提供するため、セキュリティ上の理由であるとのことでした。

彼によると、リスクは、ストアド プロシージャを介して ID が提供された場合、アプリケーションが 1 つの行だけではなく、1 つのテーブルのすべての行を削除する可能性があるということです。

わずか 15 のテーブルに対して、これはやり過ぎだと思います。

あれについてどう思う？

4

2 に答える 2

1

Linq to SQL を使用するよう DBA に提案しましたか? そうすれば、個々の行を表すオブジェクトを抽出でき、誤って複数の行を削除する可能性がはるかに低くなります。

個人的には、EDM は DB のサイズに対してやり過ぎかもしれないと思います。

私は LINQ to SQL の大支持者であり、SP の大ファンではありません....

于 2013-05-22T12:48:24.990 に答える
0

ODP.NET 上の LINQ2SQL は優れたスタックです。そして、Andrew に同意します。なぜなら、レコードをロードし、それらをすべて削除し、変更をコミットするためのコードを作成する必要があるからです。これは、「簡単に」実現できるものではありません。

LINQ ステートメントの where 句を忘れることは、ストアド プロシージャの where 句を忘れることほど簡単でも難しいことでもありません。

于 2013-05-23T00:16:58.750 に答える