私は本質的に、ビジネスロジックから完全に分離されたデータベースレイヤを持っています。つまり、ビジネスデータをデータベースにコミットする準備ができたら、すべてのビジネスプロパティをデータメソッドのパラメータに渡す必要があります。たとえば、次のようにSQLパラメータを処理する最良の方法は？
Public Function Commit(foo as object) as Boolean
これは正常に動作しますが、私はコミットとパラメータの数十を取るアップデートに入るとき、それはタイピングの多くをすることができます。私のメソッドのうちの2つ（更新と作成）は、基本的に同じことをするので、同じパラメータを使用します。私が思っていることは、これらのパラメータを渡すための最適な解決策は何でしょうか。私は両方のメソッドでパラメータを変更する必要はありません。可能な解決策。 1つは、すべてのsqlパラメータをデータクラスのクラスレベルに移動し、ビジネスレイヤで設定した配列に格納することです。どんな助けも便利です！
返信いただきありがとうございますが、私は自分が行っていることに対してより良い方法を見つけたと思います。これはupsertの使用に似ていますが、私が行うことは、特定の主キーを探すCommitと呼ばれる方法が1つあることです。レコードがデータベース内に見つかった場合は、更新コマンドを実行します。そうでなければ、私は挿入コマンドを実行します。パラメータは同じなので、変更する必要はありません。
本質的にListのParametersを渡しますか？
なぜCommit関数をやり直して、List of Parameterオブジェクトを受け入れないのですか？
私はこれが道のりだと思っていますが、誰かが別のものを思いつくのを待つつもりです。 – Austin
SQL 2008の場合、マージを使用して挿入/更新ジャグリングを置き換えることができます。時々upsertと呼ばれる。
ありがとうございます。それは本当にクールな機能です。残念ながら、私は2005年か2000年を使わなければならないかもしれません。 – Austin
structを作成して、パラメータ値を保持することができます。
あなたの問題のために、私はイテレータのデザインパターンが最良の解決策だと思います。インターフェイスの実装でICommitableValuesを渡すと、このようなキーペアの列挙値を渡すことができます。キーは列名であり、値は列コミット可能値です。プロパティは、これらの値やストアプロシージャなどを挿入するテーブル名を返すためにも使用されます。
入力を保存するには、宣言型プログラミング構文（Attributes）を使用して、コミット可能なプロパティとミドルウェアのメインクラスリフレクションを使用してこれらのコミット可能なプロパティの値を抽出し、そこからICommitableEnumeration実装を準備できます。
あなたはDALの中であなたのコードを精緻化できますか？オブジェクトをDALメソッドに渡して、そのオブジェクトのプロパティにパラメータを設定していますか？ –
Russ：はい、私はそれをやっていますが、私が渡しているオブジェクトは、独自のプロパティを持つクラスオブジェクトではなく、ネイティブCLR型です。 – Austin