Question

In domain driven design, it appears to be a good practice to use Factories to create your domain objects in your domain layer (as opposed to using a direct constructor or IoC).

But what about using the domain object factories in a presenter layer. For instance, say that I was creating a domain object from user input obtained from the presenter.

Here’s an example, say I have a Configuration domain object that has a number of decimal settings.

public class Configuration : PersistantObject {

 public decimal temperature {get;set;}   ...(times 20)   public decimal gravity {get;set;} 

}

In order to create this object in the domain layer, rather than the presenter layer, I would have to pass each of these decimal values as function parameters. Creating an unwieldy function definition and call.

ie ConfigurationService.CreateConfiguration(temperature, …(x20), gravity);

The perhaps better solution would be to create the Configuration object in the presenter layer, and assign all the values of the configuration object directly from the user input, skipping a lengthy function call.

Configuration config = ConfigurationFactory.CreateNewConfiguration();

config.temperature = temperature;

..(x20).. = …;

config.gravity = gravity;

ConfigurationService.SaveNewConfiguration(config);

But I’m wondering if this approach is wrong and why? If both of these approaches are wrong, what is the best approach for creating a lengthy object from user input and why?

Thanks!

Answer 1

I’d advise against letting your domain objects out of the domain layer and into the presentation layer. Keep the presentation layer focused on presentation.

For this reason, I construct Data Transfer Objects to shuffle data to and from the domain and presentation layers. In your case, have the dialog populate a DTO that is passed to your service and translated into the corresponding domain object.

You wouldn’t want to construct domain objects from DTOs every time, though. Consider the case where a DTO represents only a subset of a domain object. Re-constructing an existing domain object from such a DTO would give you a partial domain object. You’d probably want to maintain a light-weight cache that held the full domain object so you could do a proper update.

Essentially, you’d arrive at the DTO solution if you applied the Introduce Parameter Object refactoring.