0

私はしばらくの間 C# でプログラミングを行ってきましたが、デザイン パターンや OOP の適用が苦手で、現在変更しようとしています。

私が抱えている問題は、「SQLConn」というクラスにすべての SQL ステートメントがあることですが、代わりにそれを子クラスに分割したくないということです。

私のアプリケーションには、データベースと、「ルール」と「ログ」の 2 つのテーブルがあります。

私の考えは、(アプリケーションで使用している) テーブルごとに子クラスを作成し、すべてのメソッドをそのクラスに移動して、新しい接続を開くことです。

したがって、SQLConn の子クラスである SQLLog と SQLRules という子クラスがある場合、ユーザーがアプリケーションに新しいルールを挿入するときに、SQLConn.SQLRules の新しいインスタンスを作成し、「InsertRule()」を実行することをお勧めします。また、SQLConn.SQLLog の新しいインスタンスを作成し、"InsertLog("User inserted Rule X")? を実行します。

この投稿によると、1回の接続で多くのSQLコマンドを実行する方が良いですか、それとも毎回再接続する方が良いですか? 接続プールがアクティブになるため、パフォーマンスに大きな違いはありません。

質問を要約すると: 次のような SQL クラスを設計するのは良いことですか? InsertRule()」メソッド

また、アプリケーションの一部で SQLRules と SQLLog の両方が必要な場合、SQLLog と SQLRules の 2 つのインスタンスを作成し、それぞれのメソッドを呼び出す必要がありますか? これは良いデザインですか？

よろしく、トーマス

4

1 に答える 1

1

独自の接続を持つ 2 つの別個のクラスがある場合、同じ接続文字列を持つ適切なバージョンの SQL Server を使用していれば、接続はプールされます。

設計に関しては、データベースとアプリケーション コードを分離することをお勧めします。つまり、SQL データベース内のストアド プロシージャとして (動的 SQL または LINQ-SQL などでない限り) SQL コードを DB に配置します。ストアド プロシージャの使用をめぐるいくつかの競合がありますが、あなたの場合は適切だと思います。

その後、実際にコード内に SQL コードを文字列として含めることなく、C# コード内でこれらの sproc を呼び出すメソッドを使用できます。これは、Visual Studio ではなく SSMS で SQL コードを操作できるため、一般的に保守が容易です。

それができない場合は、少なくとも SQL コードをプロジェクト内の独自のスクリプト ファイルに入れます。

これは悪い考えではないように思えます。Demeter の法則に従って機能を分割することは、プロジェクトをよりテストしやすく、保守しやすくするための良い方法です。

于 2013-09-04T18:05:14.597 に答える