Struct vs static class for a shared resource?
<p>I have a product image class. This is an object with re-use potential for general work with images (e.g. for a product, for a CMS when working with images, etc). It will let me set the title of the file, and edit the image in simple ways using standard .NET classes.</p>

<p>I can use a struct, which means if I use the struct in 5 different places, that's 5 different memory locations but all indepdent of each other. Change the state of one these memory locations does not effect the others (which is the desired behaviour). It will be boxed when asking for an object.</p>

<p>The object is instance based. So every product would use the product object and work with the image (e.g. edit its title, etc).</p>

<p>If I make a static class, that is five different locations referring to one object. So I would need to take care of thread synchronization. I can't just write to a variable as another access might overwrite the variable, regardless of how well I synchronize access to this shared resource. So I always need to return new variables. Also, if I use a static class which is used by many different calling methods, that would cause a queue to access the shared resource. Because utility classes are static and they are just that - utilities - they will be used by many classes throughout my codebase. Is it perhaps not wise to use static classes in this situation?</p>

<p>As the MSDN documentation explains, I will only use a static class for a global entity. So a class which encapsulates details about my codebase - there is only one codebase, and this class will contain details on the line count, etc. This is not instance based, like an order class (1 customer-1 order-1 or more orders).</p>

<p>In this sort of scenario, is it a good design decision to perhaps use a struct instead?</p>
