3

私は適切なタイトルを考え出すために最善を尽くしました、それがあまり意味をなさない場合は言い訳をします。以下で詳しく説明したいと思います。.Net Frameworkに基づいており、データストレージとしてSQLを使用するアプリケーションがあります。他のアプリケーションと同様に、このアプリケーションは、たとえば追加のデータ変換と検証をサポートするために、拡張性をサポートする必要があります。

例：アプリケーションを、ユーザーがアクセスまたはExcel（UIとグリッドが既に存在する）を使用してデータをインポートし、データのインポートを可能にする一連の入力テーブルを提供するツールと考えてください。データがインポートされると、ツールは中間モデルを作成し、入力データに対していくつかの計算を実行し、後で結果を事前定義された形式でスローします。入力テーブルスキーマと中間モデルスキーマは固定されており、変更は行われません。中間モデルが入力データから導出される段階では、拡張性が必要です。ユーザーがデータの取得方法を変更できるようにします。たとえば、1つのフィールドでグループ化する代わりに、複数のフィールドでグループ化できるようにします。

この種の柔軟性をサポートするために、私が見ることができるように2つの基本的なアプローチがあることがわかります

オプション1：SQLデータモデルにマップするビジネスモデルを作成し、ビジネスモデルをユーザーに公開して、ユーザーが変換をオーバーライドし、新しい変換を作成できるようにします（たとえば、LINQまたはプレーンC＃を使用）

オプション2：SQLデータモデル全体を公開し、ユーザーが生のSQLクエリを埋め込んで変換と検証を実行できるようにします。

私の個人的な好みはオプション1を使用することです。なぜなら、ユーザーが基になるデータテーブルを直接操作できるようにすることはあまり好きではないからです。私はより制御されたアクセスを好みます。ただし、このアプローチでは、ユーザーはプログラミング言語（C＃またはVB）を使用する必要があります。一方、オプション2では、生のクエリを作成してアプリケーションに直接プラグインするために、SQLプログラミングの知識を持った人が必要な場合があります。しかし、これは悪いアプローチだと思います。

製品管理チームは、リソースの観点から、より柔軟で実装が容易であると感じているため、オプション2を採用する傾向があります。

そのため、オプション1の傾向をより適切にサポートするために、両方のアプローチの長所と短所を考え出そうとしています。基本的に、単純なSQLクエリを使用するのではなく、C＃またはVB.netのプログラミング言語で作業を行う傾向があります。

ご意見・ご感想をお聞かせください。

4

1 に答える 1

6

どちらのオプションも適切ではありません。

エンドユーザーは（理論的には）ビジネスロジックに精通しています。仕事をするためにプログラミング言語に精通している必要はありません。

コンボボックス、テキスト入力、グリッドなどの標準的なコントロールを使用して拡張するためのフレームワークを作成する必要があります。探している拡張性の種類を具体的に説明しないと、具体的なアドバイスを提供することは困難ですが、ここで説明します。あなたは私のプロジェクトからの例です：

ユーザーは、Webサイトでフィルタリングするために、製品に任意のタグを追加する方法を必要としています。タイプの名前を入力し、それが「True / False」、整数、10進数、またはリストの値のいずれであるかを指定して、そのリストの項目を設定できるデータグリッドを作成しました。次に、各製品で、該当するすべてのタイプのリストが表示され、値を入力する必要があります。「True / False」はチェックボックスを生成し、整数と小数は検証するテキストフィールドを生成し、リストは指定したすべてのオプションのコンボボックス。新しいプロパティが必要なときはいつでも、自分で追加できますが、Webサイトはタイプに基づいて動作するため、これらのプロパティがどのように機能するかを考える必要はありません。

わかりました、あなたの例に基づいて、私はこれを提案します：

データのすべての列をリストし、その横に実行するアクションを指定するためのコンボボックスがあるフォームを提供します。アクションは、次のようなものを含むリストから選択できます。

  • データを無視する
  • データをそのまま使用する
  • データをフォーマットする
  • 他の場所で価値を調べる
  • 計算を実行します

このドロップダウンでのユーザーの選択に基づいて、次のようにします。

  • 出力に列を含めない
  • データはそのまま使用してください。
  • String.Formatデータのタイプに基づいて（おそらくオプションのサブセットを使用して）データをフォーマットできるフォームを開くためのボタンを提供します。サポートされている値を示すために、下部にキーを表示します。
  • 「他の場所」が何であるかを指定するためのボタンを提供します。 これはおそらく拡張性が最も役立つ場所なので、以下で再度説明します
  • 適切な計算を入力する方法を提供します。

「他の場所」のルックアップに関しては、これはおそらくそれを変換するための値と文字列のリストです。これらの値は、アプリケーションの構成セクションで指定し、テーブルのどこかに格納できます。それらの任意のグループを作成して、オプションのさまざまな「リスト」を表すことができます。または、ユーザーに参照してもらいたい既存のデータテーブルをいくつかリストし、（計算画面を使用して）変換を指定して、値を他のテーブルのルックアップに変換することもできます。

これは理にかなっていますか？

于 2012-11-01T18:55:38.783 に答える