views:

400

answers:

1

Hi Folks

I'd like to store an image in a business object. In MSDN I saw that the System.Drawing-namespace provides lots of GDI+-features, etc.

Is it okay to store an Image in an System.Drawing.Image class in business layer (which is a class library "only"), and thus including a reference to System.Drawing too? I slightly feel just kind of bad doing that, 'cause it seems like I have UI-specific references in business code. Moreover, the code could become unnecessarily platform-dependant (though this is only a problem in theory, because we do not develop for multiple platforms).

If it isn't right that way, which type would fit best?

Thank you for any response!

Matthias

+2  A: 

From your question, it seems apparent that your business logic layer needs to process images in a pretty low-level way (otherwise, I guess you'd just be storing image URLs or something...). This places the concept of an image/bitmap squarely in the business logic territory, so it's perfectly fine for it to rely on the System.Drawing namespace for this purpose.

If you feel like images have no place in a class library, one look System.Drawing itself should convince you otherwise: it's a prime example of a class library (and a very decently designed one at that) that pretty much does nothing else than deal with images.

It really doesn't have anything to do with UIs (Windows.Forms and friends deal with those). Also, System.Drawing is present on any system with the .NET Framework installed, so there are no dependency issues.

If you're concerned about cross-platform compatibility, creating a wrapper class for images could alleviate these concerns. However, since the bitmap structures themselves are most likely already platform-specific (unless you take care to only use PNGs on your external interfaces, for example), this might be a bit over the top, since you're adding complexity without gain...

mdb
Many thanks for your reply! I think there's nothing to be added, very nice :)
Mudu