Should business objects be able to create their own DTOs?

Question

Suppose I have the following class:

class Camera
{
    public Camera(
        double exposure,
        double brightness,
        double contrast,
        RegionOfInterest regionOfInterest)
    {
        this.exposure = exposure;
        this.brightness = brightness;
        this.contrast = contrast;
        this.regionOfInterest = regionOfInterest;
    }

    public void ConfigureAcquisitionFifo(IAcquisitionFifo acquisitionFifo)
    {
        // do stuff to the acquisition FIFO
    }

    readonly double exposure;
    readonly double brightness;
    readonly double contrast;
    readonly RegionOfInterest regionOfInterest;
}

... and a DTO to transport the camera info across a service boundary (WCF), say, for viewing in a WinForms/WPF/Web app:

using System.Runtime.Serialization;

[DataContract]
public class CameraData
{
    [DataMember]
    public double Exposure { get; set; }

    [DataMember]
    public double Brightness { get; set; }

    [DataMember]
    public double Contrast { get; set; }

    [DataMember]
    public RegionOfInterestData RegionOfInterest { get; set; }
}

Now I can add a method to Camera to expose its data:

class Camera
{
    // blah blah

    public CameraData ToData()
    {
        var regionOfInterestData = regionOfInterest.ToData();

        return new CameraData()
        {
            Exposure = exposure,
            Brightness = brightness,
            Contrast = contrast,
            RegionOfInterest = regionOfInterestData
        };
    }
}

or, I can create a method that requires a special IReporter to be passed in for the Camera to expose its data to. This removes the dependency on the Contracts layer (Camera no longer has to know about CameraData):

class Camera
{
    // beep beep I'm a jeep

    public void ExposeToReporter(IReporter reporter)
    {
        reporter.GetCameraInfo(exposure, brightness, contrast, regionOfInterest);
    }
}

So which should I do? I prefer the second, but it requires the IReporter to have a CameraData field (which gets changed by GetCameraInfo()), which feels weird. Also, if there is any even better solution, please share with me! I'm still an object-oriented newb.

Answer 1

I would generally say no, they shouldn't, because DTOs are specific to a service or application, whereas the domain model is your "innermost" layer and should have no dependencies. DTOs are an implementation detail of something other than the domain model, and therefore, it's breaking the abstraction for your domain model to know about them.

Have you considered looking at AutoMapper for this? You'll end up writing a lot less code that way. In this case, I think you'd be able to get away with simply:

Mapper.CreateMap<RegionOfInterest, RegionOfInterestData>();
Mapper.CreateMap<Camera, CameraData>();

And later on:

CameraData cd = Mapper.Map<Camera, CameraData>(camera);

This not only reduces the code churn but compartmentalizes the mapping code in its own "mapping layer" - you have one or several modules that register these mappings that you can put in whichever assembly really uses the DTOs.

And of course you can always create extension methods to simplify the actual mapping:

public static class CameraExtensions
{
    public static CameraData ToCameraData(this Camera camera)
    {
        return Mapper.Map<Camera, CameraData>(camera);
    }
}

Which makes the whole thing as simple as writing camera.ToCameraData(), but without creating a hard dependency between the domain object (Camera) and the DTO (CameraData). You have basically all of the ease-of-use of your original version, but without the coupling.

If you're creating these dependencies because you're trying to create the CameraData object from private Camera data which isn't exposed publicly then my immediate reaction would be, something's not quite right about this design. Why not expose read-only properties on the Camera object? If you're giving the outside world access to them anyway, through the ToData method, then you're clearly not hiding this information, you're just making it more cumbersome to get to.

What if you decide 3 months down the road that you need a different kind of DTO? You shouldn't have to modify your domain-centric Camera object every time you want to support a new use case. Better, in my opinion, to put a few read-only public properties in the class so that mappers can get access to the attributes they need.

Answer 2

I usually go about it this way: The business objects are "pure" in the business layer DLL(s). I then add a Camera.MapToCameraDataContract extension method in the WCF layer. I also typcially have the reverse extension method (CameraDataContract.MapToCamera) on the service layer as well.

So in essence, I do it the first way, but the ToData method is an extension method that only the WCF layer knows about.