4

ますます多くのプロジェクトを抱えているため、プロジェクトからプロジェクトへ、クライアントからクライアントへと、多くの一般的なタスクを繰り返していることがよくあります。そこで私は、プロジェクトからプロジェクトへと繰り返されることが多いこれらの共通要素のコレクションである「ユーティリティ」ライブラリの構築を開始しました。

これまでのところ、画像のサイズを変更したり、データ グリッドを Excel にエクスポートしたり、電子メールを送信したり、トークン化されたメッセージを置き換えたりするためのユーティリティがあります。

.NET ユーティリティ クラス ライブラリを構築または使用している場合、どのような種類のプロセスが役立つと思いますか? どの名前空間/グループを想像しますか?

アップデート

私は、共通の要素をグループ化するために名前空間に分割された実際のクラス ライブラリについて話しています。

4

5 に答える 5

5
  1. 「Common」、「Utilities」、「Misc」などの名前のライブラリは作成しません。代わりに、「Lib」というディレクトリを作成し、その下の個別のライブラリに各機能領域を配置します。たとえば、C++ プロジェクト用に Lib/Trace、Lib/UI、Lib/Net、Lib/Web があるとします。C# の場合、Lib/Acme.Trace、Lib/Acme.Windows.Forms、Lib/Acme.Net などがあります (最上位の名前空間/会社が「Acme」と呼ばれていると仮定します)。
  2. ヤグニ。必要になるかもしれないコードを書きに行かないでください。
  3. 2 つ以上のプロジェクトで使用するまでは、共有ライブラリに物を投げ込まないでください。
于 2009-01-02T19:12:41.597 に答える
1

個人的には、この機能の一部を別のライブラリに入れたいと思います。「ユーティリティ」はかなり主観的な用語であり、ある人が役立つと思うものは別の人にはあまり役に立たないからです。

ライブラリ内で説明的な名前空間に分割されている場合は、そのほうがよいと言えます(たとえば、画像のサイズ変更は、ある種の .Drawing 名前空間または .Drawing.dll になります)。

于 2009-01-02T19:09:27.627 に答える
1

クラス ライブラリには、プロジェクト間で共有するものがたくさんあります。

  • IoC コンテナと依存性注入フレームワーク
  • 完全なコントローラー/オブザーバー フレームワークにより、UI コードをバックロジック コードから分離できます
  • SQL を実行するための合理的なデータベースに依存しないクラスのセットは、主に関数名など、いくつかの構文の違いを処理します。
  • データを扱うための他の多くのヘルパー クラスとユーティリティ メソッド
  • Tuple<..>などのいくつかの標準化された内部ストレージ クラス。
  • Set<T>、 などのいくつかのカスタム コレクションと、Heap<T>さまざまなタイプのコレクションを処理するための多数のユーティリティ メソッド

クラス ライブラリは、さらに必要なときに追加されます。

于 2009-01-02T19:15:52.090 に答える
1

「ユーティリティ」ライブラリの代わりに、ドメイン固有の (グラフィック、認証、検証など) ライブラリを作成し、必要な場所にのみ含めることをお勧めします。もちろん、キーはどれだけ具体的であるかによって決まります。一般に、特異性が高いほど優れています。

それがドメインを持っていない場合でも、それを完全に理解していない可能性があります。つまり、最初に何をして何を達成しようとしているのかを再評価する必要があります.

また、1 つまたは 2 つのプロジェクトで役立つものが、1 つまたは 2 つのプロジェクトでのみ役立つ可能性があることも忘れないでください。必要以上のクラスを追加しても、将来的にメンテナンスの問題が発生するだけです。

于 2009-01-02T19:57:26.780 に答える
0

私自身は駆け出しの開発者ですが、RegEx 関数と SQL フィルターが非常に便利であることがわかりました。また、これまで非常に便利だった MSSQL のマージ レプリケーション機能もあります。

于 2009-01-02T19:13:48.100 に答える