Using Factories in Presenters in a Model View Presenter and Domain Driven Design Project

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

There are two main ways I would handle this

1) If this is setup through a dialog I would create classes implementing the command pattern and bind a dialog with the object in question. For example CmdCreateConfigurationService, and CmdEditConfigurationService.

CmdCreateConfigurationService would rely on a factory class and minimum parameters you need to select the correct Configuration Service.

You setup a IConfigurationServiceEditor interface and pass that as one of the parameter to CmdEditConfiguration Parameters. With the IConfigurationServiceEditor interface you define as many methods as you need to make the transfer of information from and to the dialog easy and painless as possible. I recommend using a collection of keys and values.The Command Object knows how to setup up the Configuration Service from this collection. The Dialog know to expect this collection when setting up.

Regardless of the data structure you will do the work of filling out the Configuration Service in the command object. By having non dialog/form/screen object implement IConfigurationServiceEditor you can automate your testing and in certain circumstances make configuration of complex objects easiers.

I developed this method for a CAD/CAM softaware that has several dozen parametric shapes each having from 4 to 40 entries.

Answer 2

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.