C# WPF - Is it acceptable to have a dependency to PresentationCore.dll in domain layer?

Question

We are working on a .NET desktop application written in C# and WPF, that communicates with a REST API server. The software has a layered design and consists of multiple projects.

• One project for the presentation and ViewModels (we follow the MVVM pattern).
• One project for the domain layer. The business logic like services and model classes.
• One project for the implementation of the data layer. (In this case mainly the communication with the REST API). In the future there could be more projects for the data layer, that all have different implementations of data-ralated interfaces that are defined in the 'domain' project.

Our REST API provides an endpoint for loading images, and we want to create a service in the domain layer that makes it possible to load those images. This would mean the service class could look something like:

public class ImageService 
{
    public BitmapImage GetImage(int imageId)
    {
        // ...
    }
}

But the above class has a dependency to BitmapImage, or in other words: PresentationCore.dll. This seems to be no good for a service class in a domain layer. At the same time, it would be very useful to have this kind of service. On one hand, BitmapImage lets me think of a typical UI related object, but on the other hand BitmapImage seems to be suitable because you could consider it as a standalone class representing an image, and it is usable without any UI context (I mean, it's not a UI control/layout, doesn't depend on other UI related classes, etc.)

The problem is: is it acceptable to have a dependency to PresentationCore.dll in a project that's a pure logical domain layer. Also, a reference PresentationCore.dll implies that the project could contain more usages of classes in that DLL, and possibly makes it unclear why that DLL is referenced at all. Maybe even the mistake/temptation exists someone's going to use UI related objects from this DLL?

What would be a solution for loading images in this case?

Answer 1

Split the "data" and the "view": the REST side will get a binary blob which is the image in some format. Store this in an object. This goes in the data layer.

The presentation layer then needs a converter for those objects, and possibly a cache of converted images, but does no REST work.

Answer 2

Depending on what you're doing with the image data, there might not be a need to create a BitmapImage object in your image service.

If you're just going to display it in an Image control, then your image service can just return a byte array which you can bind directly to the image control's Source property, and the control will automatically generate the displayed image from that.

So your ImageService could be coded as

public byte[] GetImage(int imageId) { ... }

or even

public Task<byte[]> GetImageAsync(int imageId) { ... }

if the image data is being fetched from a slow source such as local file read, database or web service.

The latter form could be combined with an asynchronous property, to allow the image data to be fetched, when required, without blocking the UI thread. For an example of this, check out my blog post.