0

在域驱动设计中，使用工厂在域层中创建域对象似乎是一种很好的做法（而不是使用直接构造函数或 IoC）。

但是在表示层中使用域对象工厂呢？例如，假设我正在根据从演示者获得的用户输入创建域对象。

这是一个示例，假设我有一个配置域对象，该对象具有许多十进制设置。

公共类配置：PersistantObject {

 public decimal temperature {get;set;}

 ...(times 20)

 public decimal gravity {get;set;}

}

为了在域层而不是演示者层中创建这个对象，我必须将这些十进制值中的每一个作为函数参数传递。创建一个笨拙的函数定义和调用。

即 ConfigurationService.CreateConfiguration(温度, ...(x20), 重力);

也许更好的解决方案是在演示者层创建配置对象，并直接从用户输入分配配置对象的所有值，跳过冗长的函数调用。

配置配置 = ConfigurationFactory.CreateNewConfiguration();

配置温度=温度；

..(x20).. = ...;

config.gravity = 重力；

ConfigurationService.SaveNewConfiguration(config);

但我想知道这种方法是否错误，为什么？如果这两种方法都是错误的，那么从用户输入创建长对象的最佳方法是什么？为什么？

谢谢！

4

2 回答 2

2

我建议不要让您的域对象离开域层并进入表示层。让表现层专注于表现。

出于这个原因，我构造了数据传输对象来在域和表示层之间进行数据混洗。在您的情况下，让对话框填充传递给您的服务并转换为相应域对象的 DTO。

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.

于 2009-01-08T03:24:05.877 回答
0

我有两种主要的方法来处理这个

1）如果这是通过对话框设置的，我将创建实现命令模式的类并将对话框与相关对象绑定。例如 CmdCreateConfigurationService 和 CmdEditConfigurationService。

CmdCreateConfigurationService 将依赖于您选择正确配置服务所需的工厂类和最小参数。

您设置一个 IConfigurationServiceEditor 接口并将其作为参数之一传递给 CmdEditConfiguration 参数。使用 IConfigurationServiceEditor 接口，您可以根据需要定义尽可能多的方法，以尽可能轻松地在对话框之间进行信息传输。我建议使用键和值的集合。命令对象知道如何从这个集合中设置配置服务。对话框知道在设置时期望这个集合。

无论数据结构如何，您都将完成在命令对象中填写配置服务的工作。通过让非对话框/表单/屏幕对象实现 IConfigurationServiceEditor，您可以自动化您的测试，并在某些情况下使复杂对象的配置更容易。

我为 CAD/CAM 软件开发了这种方法，该软件有几十个参数形状，每个形状有 4 到 40 个条目。

于 2009-01-07T22:36:44.133 回答