0

こんにちはすべて私たちは、SqlCommandオブジェクトのCommandTypeプロパティに、TableDirect、Text、およびStoredProcedureまたは「SP」の3つのオプションがあることを知っています。

「SP」には他の2つのオプションよりも利点があることを知っているので、私の質問は、自分のシステムで多くのSPを作成するかどうかです。

または、SPを作成する代わりに、どのようなソリューションがありますか？

ありがとうございました

4

4 に答える 4

1

すべての本番システムで、SPと純粋なADO.NETCoreを使用してデータにアクセスしました。システムの範囲は、100〜300のテーブルと約500〜1000のストアドプロシージャです。

ほとんどのデータアクセスコードは、ツールを使用して生成されます。ソースコードとサンプルアプリケーションの使用/変更に興味がある場合は、ブログに投稿しました。このツールは、約750のストアドプロシージャを含むデータベースに対して、約20〜25秒で100,000行を超えるコードを生成できます。

データアクセス層-コード生成

もちろん、データベース、データモデリング/設計、およびストアドプロシージャに精通していない場合は、Linq to SQLまたはEF4（Entity Frameworkバージョン4）などを使用することをお勧めします。ブルートフォースのパフォーマンスが必要な場合は、ADO.NETコアとストアドプロシージャが最適です。

于 2011-01-27T06:23:56.093 に答える
1

ストアドプロシージャを作成する以外に、オブジェクトリレーショナルマッピングを使用できます

そのような：

linq to sql
Nhibernate
Entity Framework

データアクセス：SPとORM

あなたに合った最良の方法を選択してください。

于 2011-01-27T06:38:51.120 に答える
1

Re：最初の質問 ストアドプロシージャの道を進むと、プロジェクトの存続期間中、ストアドプロシージャの数が増え続けます。基本的なCRUD操作以外では、各ストアドプロシージャは特定の問題に緊密に結び付けられ、再利用性が低い傾向があります。経験則では、各データテーブル（州や国のリストなどの参照テーブルまたはコードテーブルを除く）に対して8〜12個のストアドプロシージャを期待できます。

procの数が非常に多いため、命名規則が非常に重要になるため、400〜500のprocのリスト全体を常に視覚的に再スキャンしなくても、何でも見つけることができます。

Re：2番目の質問 C＃またはVB.NET内の文字列内に記述されたSQLで発生する醜いことがたくさんあります。エラーが発生しやすい、醜いなどです。

Linq、nHybernateなど多くの存在がありますが、「コンセプトカウント」（生産性を高めるために学ぶ必要のあるものの数）は、C＃で優れたストアドプロシージャエグゼキュータを作成する方法を学ぶよりもはるかに多くなります。

于 2011-01-28T20:28:22.780 に答える
0

ストアドプロシージャは、ビジネスロジックではなく、データベース機能のためだけに作成されるようにしています。

少しあいまいなデータベースアーキテクチャがあり、それを呼び出し元から隠したい場合は、データベース機能です。

それが単に私のアプリケーションが追加または更新する方法である場合、またはそれらが行う検証の量などである場合、それはビジネスロジックです。

于 2011-02-25T02:43:44.273 に答える