Home/ Questions/Q 492037
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T02:04:17+00:00

Before I begin, similar questions but not exact: Working with Common/Utility Libraries , What

  • 0

Before I begin, similar questions but not exact:
Working with Common/Utility Libraries,
What to include in a Utility Library.

I have recently starting working with our company’s internal C# libraries, which include Common.dll and Utilities.dll; pretty standard stuff.

My current plan is to refine these two libraries into two very separate entities, that have very separate usages. However, I haven’t figured out where to draw that line.

Rather than give details on what each contains, I would like neutral advice on what you would throw into each of these, in that, how you would define that barrier. I do not need uberspecifics.

There is also the argument that these two should be consolidated into a single library. (see above links) I am open to that idea if there is no suitable alternative. I am more interested in the difference between the two though.

Thanks in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You speak as though “Common” and “Utility” have well understood meanings. I don’t recognise that there should be such a separation, or if do some organisation of reusable code that there should be two such categories.

    First I would distinguish between a body of code that tends to get reused in production applications and a a body of code that might only be used for testing.

    Then to focus on production applications I would expect there to be Business Domain common code (for example code to deal with Foreign Exchange, or Car Hire Mileage Rates, or whatever your business happens to be.) and more general purpose utilities such as Logging, or String Formatting, or Some Clever Math). I think you’ll find pieces of code that in some way “belong together” and some you want to keep separate. Some possible criteria:

    • Rate of change: when this changes, that probably changes too, so we need to release them together
    • Overhead – this chunk is big, only apps that need should pay the price of including or deploying it.
    • Scope – this is UI code, that is database code, keep them separately
    • Dependency – if you use this, then you also use that, so keep theOther separate, he doesn’t need that
    • Avoid cyclic dependencies, decompose and recorganise to avoid those
    • 0