0

基本的に、ビジネスロジックから完全に分離されたデータベースレイヤーがあります。つまり、ビジネス データをデータベースにコミットする準備ができたら、すべてのビジネス プロパティをデータ メソッドのパラメーターに渡す必要があります。例えば:

Public Function Commit(foo as object) as Boolean

これは問題なく動作しますが、数十のパラメーターを使用するコミットや更新を行うと、大量の入力が必要になる場合があります。言うまでもなく、私のメソッドのうちの 2 つ (update と create) は、本質的に同じことを行うため、同じパラメーターを取ります。私が疑問に思っているのは、これらのパラメーターを渡すための最適な解決策は何であり、何かが変更されるたびに両方のメソッドでパラメーターを変更する必要がなく、入力を減らす必要がないということです:)私はいくつか考えました可能な解決策。1 つは、すべての SQL パラメーターをデータ クラスのクラス レベルに移動し、ビジネス レイヤーで設定したある種の配列にそれらを格納することです。どんな助けでも役に立ちます!

4

5 に答える 5

0

あなたの問題については、イテレータのデザインパターンが最善の解決策だと思います。インターフェイス実装を渡すと、このようなキーペア列挙値を渡すことができるICommitableValuesと言います。キーは列名であり、値は列のコミット可能な値です。プロパティは、これらの値を挿入したり、プロシージャなどを格納したりするテーブル名を返すために使用されます。

入力を節約するために、宣言型プログラミング構文(属性)を使用してコミット可能なプロパティを宣言できます。ミドルウェアのメインクラスは、リフレクションを使用してこれらのコミット可能なプロパティの値を抽出し、そこからICommitableEnumeration実装を準備できます。

于 2009-04-22T18:02:07.183 に答える
0

つまり、本質的にList of Parametersを渡したいですか?

Commit 関数をやり直して、Parameter オブジェクトのリストを受け入れるようにしてみませんか?

于 2009-04-17T19:27:09.423 に答える
0

SQL 2008 を使用している場合は、マージを使用して挿入/更新ジャグリングを置き換えることができます。アップサートと呼ばれることもあります。

于 2009-04-17T19:27:14.850 に答える
0

structパラメータ値を保持する を作成できます。

于 2009-04-17T19:30:17.887 に答える
0

ご回答ありがとうございます。upsert を使用するのと似ていますが、私が行っているのは、指定された主キーを探す Commit という 1 つのメソッドです。データベースでレコードが見つかった場合は、更新コマンドを実行します。そうでない場合は、挿入コマンドを実行します。パラメータは同じなので、変更する必要はありません。

于 2009-04-22T17:53:05.660 に答える