ユーティリティライブラリに含めるもの

Question

ますます多くのプロジェクトが私のベルトの下にあるので、私は多くの場合、プロジェクトからプロジェクト、クライアントからクライアントに多くの一般的なタスクを繰り返していることがわかります。だから、私は<！> quot; utility <！> quot;を組み立て始めました。ライブラリ、これらの共通要素のコレクションであり、プロジェクトからプロジェクトへと頻繁に繰り返されます。

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

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

更新

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

Answer 1

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つ以上のプロジェクトで使用するまで、共有ライブラリに物を投げ込まないでください。

Answer 2

個人的には、この機能の一部を<！> quot; utility <！> quot;として別のライブラリに配置します。主観的な用語であり、ある人が役に立つと思うことは、他の人にとってそれほど役に立たない。

ライブラリ内で説明的な名前空間に分割された場合、それは better と言えます（たとえば、画像のサイズ変更は何らかの種類の.Drawing名前空間または.Drawing.dllにあります） 。

Answer 3

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

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

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

Answer 4

<！> quot; utility <！> quotではなく、ライブラリは、ドメイン固有（グラフィック、認証、検証など）のライブラリを作成し、必要な場所にのみそれらを含めます。もちろん、キーはどの程度具体的であるかを決定します。一般に、特異性が高いほど優れています。

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

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

Answer 5

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