3

DBへのすべてのクエリにストアドプロシージャを使用しています。これは信じられないほど乾燥していないようです：

  1. テーブルをデザインする
  2. そのテーブルのCRUD操作SPを設計する
  3. パラメータを入力してCRUDSPを実行するためのコード（できればクラス）を設計する

単一の列を追加したり、データ型を変更したりする場合は、.NET内のクラスで、テーブル、少数のSP、および少数の関数を編集する必要があります。

この重複を減らすためのヒントは何ですか？

アップデート：

ヴィンコのアイデアと組み合わせて、これを見つけました。これが必要な人のために私が思いついた（C＃の）コードです：

SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["MySQLConnString"].ConnectionString);
SqlCommand comm = new SqlCommand("NameOfStoredProcedure", conn);
comm.CommandType = CommandType.StoredProcedure;

conn.Open();
SqlCommandBuilder.DeriveParameters(comm);
conn.Close();

foreach (SqlParameter param in comm.Parameters)
{ /* do stuff */ }
4

8 に答える 8

2

NetTiersなどのコード生成ツールを使用してCRUDレイヤーを生成することをお勧めします。

于 2008-11-08T05:50:49.390 に答える
2

少なくともSPの変更を回避するための1つのヒントは、「イントロスペクション」を使用するようにSPを作成することです。つまり、内部テーブルまたはinformation_schemaビューから列名とデータ型を推測します。

記述するのはより複雑なコードですが、テーブルが変更されるたびにコードを変更する必要がなくなり、残りのSPで再利用できます。

たとえば、残りのSPから呼び出す一時テーブル（colname varchar、type varchar）を使用して、テーブルを説明する単一のSPを作成します。

ちなみに、これは非常に複雑になり、クエリが複雑な場合は実行不可能になる可能性がありますが、そうでない場合は、多くの問題を回避できます。

于 2008-11-08T06:03:13.577 に答える
1

OOPの設計原則は、宣言型コードではなく、手続き型コードを対象としています。特に、SPの再利用は非常に問題があります。

CRUDジェネレーターに基づくUIデザインはよく知られています。ユーザーを明示的にデータ入力担当者に変える別の方法。これらを使用する場合は、それらが生成するものとユーザーが処理する必要があるものとの間に優れた抽象化レイヤーがあることを確認してください。

単一の列を追加したり、データ型を変更したりする場合は、.NET内のクラスで、テーブル、少数のSP、および少数の関数を編集する必要があります。

確かに、データベース設計がOOP要件を決定しているように聞こえます。代わりに、反対方向から開始してください。

于 2008-11-08T05:53:13.613 に答える
1

これらのメタクエリアプローチはすべて、SQLが単一のテーブルを超えるとすぐにトラックで消滅します。または、計算列が必要です。または ...

于 2008-11-08T06:05:44.463 に答える
1

個人的には、クエリコードをストアドプロシージャに入れるのはあまり好きではありません。非常に複雑なことを除いて、それは冗長なやり過ぎのように思えます。

データベースとクラッドオブジェクトの設計を処理する方法は次のとおりです。

  1. データモデルを作成します
  2. テーブルごとにビューを作成します
  3. テーブルごとに挿入、更新、削除のプロシージャを作成します。
  4. 私のすべてのC＃コードは、ビューとプロシージャを指しています。

これにより、次のことが可能になります。

  1. 柔軟性の高いクエリターゲット（ビュー）を用意する
  2. 冗長性なしで必要な方法でビューに対してクエリを実行します。
  3. データベースセキュリティを介したテーブルへの直接アクセスを防止する
  4. コードを壊さずに基になるデータモデルをリファクタリングする必要がある場合に備えて、データモデルを抽象化します（これにはパフォーマンスコストがかかる可能性があります）

ターゲットテーブルを表す1つのビューがあると、おそらく多くのクエリが処理されます。そうでない場合でも、発生する最悪の事態は、クエリ専用のビューを作成する必要があることです。これは、クエリのプロシージャを作成するのと同じです。マイナス面はありません。

SQLインジェクション攻撃を防ぐためにストアドプロシージャを使用することを推奨している人がいますが、ビューをクエリするときにパラメータ化されたクエリを使用する場合、これはとにかく問題にはなりません。...そして私たちは常にパラメータ化されたクエリを使用します...そうですか？;-)

于 2008-11-09T22:49:02.487 に答える
1

使用する「DeriveParameters」アプローチは機能しますが、リクエストごとに 2 つのデータベース トリップが必要です。このアプローチでは、パフォーマンスが低下します。Microsoft の Data Access Application Block SqlHelper クラスは、まったく同じ「イントロスペクション」を行うことでこれを軽減しますが、オプションで再利用のためにパラメーターをキャッシュします。これにより、パラメーターなどを繰り返し「グー」設定することなく、単一行の SP 呼び出しを作成できます。

http://msdn.microsoft.com/en-us/library/cc309504.aspx

于 2009-03-05T15:50:52.177 に答える
0

CRUDがなく、アプリケーションからアクセスできないテーブルがいくつかあり、データベース実装モデルの成果物です。特に、多対多のリンクテーブルには、アプリケーションからアクセスしないでください。ストアドプロシージャを介してデータベースで管理する必要があります。

于 2008-11-09T22:53:15.177 に答える
0

これが実際に DRY ガイドラインに該当するとは思いません。これは単に永続性に関するものであり、#3 を手動で行っている場合は、これを容易にするツールセットの 1 つを採用することを検討する必要があります。LINQ to SQL は私の個人的なお気に入りですが、他にもたくさんあります。

＃2も簡単に自動化できます。1) データ モデルの設計 (概念) 2) 永続層での実装 (テーブルの作成または列の追加) 3) アプリケーション レベルでの使用に必要な全体的な作業を削減します。

于 2008-11-08T10:16:46.407 に答える