0

始める前に、同様の質問ですが正確ではありません:
共通/ユーティリティ ライブラリの操作、ユーティリティ ライブラリ
に含めるもの。

私は最近、Common.dll と Utilities.dll を含む社内の C# ライブラリを使い始めました。かなり標準的なもの。

私の現在の計画は、これら 2 つのライブラリを 2 つの非常に別個のエンティティに絞り込み、用途が非常に異なるようにすることです。しかし、その線をどこに引くべきか、私にはわかりませんでした。

それぞれに何が含まれているかについて詳しく説明するのではなく、これらのそれぞれに何を投入するか、つまり、その障壁をどのように定義するかについて、中立的なアドバイスをお願いします. 特別仕様は必要ありません。

これら 2 つを 1 つのライブラリに統合する必要があるという議論もあります。（上記のリンクを参照）適切な代替案がない場合、私はその考えを受け入れます。しかし、私は2つの違いにもっと興味があります。

前もって感謝します！

4

1 に答える 1

4

あなたは、「共通」と「実用性」がよく理解された意味を持っているかのように話します。私は、そのような分離があるべきだとは認識していません。また、再利用可能なコードの組織が、そのようなカテゴリを 2 つ持つべきであると認識していません。

最初に、本番アプリケーションで再利用される傾向があるコード本体と、テストにのみ使用される可能性のあるコード本体を区別します。

次に、実稼働アプリケーションに焦点を当てるために、ビジネス ドメインの共通コード (たとえば、外国為替、レンタカーのマイレージ料金、またはビジネスがたまたま何であれ) と、より汎用的なユーティリティ (Logging、または文字列の書式設定、またはいくつかの巧妙な数学)。何らかの形で「一緒に属している」コードと、別々に保持したいコードが見つかると思います。いくつかの考えられる基準:

  • 変化率: これが変化すると、おそらくそれも変化するため、それらをまとめてリリースする必要があります
  • オーバーヘッド - このチャンクは大きく、必要なアプリのみがそれを含めるかデプロイする費用を支払う必要があります。
  • スコープ - これは UI コード、つまりデータベース コードであり、個別に保持します。
  • 依存関係 - これを使用する場合は、それも使用するため、theOther を分離してください。彼はそれを必要としません。
  • 循環的な依存関係を回避し、それらを回避するために分解および再編成します
于 2009-12-10T23:49:09.770 に答える