在哪里建立新的域实体？ 控制器，存储库或映射器？

比方说，对于每个域实体，我有一个为数据映射器提供API的存储库。 例如，如果我有一个UserEntity，那么我将拥有一个UserRepository，该UserRepository与UserMapper对话以将用户数据保存在数据库中。

现在，让我们说一个表单在网页上提交，我的控制器知道它需要根据提交的信息创建一个新的UserEntity。

可以：

在当场做新的UserEntity（），并根据提交的表单数据运行所有必要的setter方法，然后将UserEntity传递给repo，然后将其传递给mapper进行插入？

控制器创建UserEntity => Repo => Mapper => DB

将表单数据转换为数组，并将其传递给UserRepository，然后运行新的UserEntity（）和setter，并将其传递给映射器以进行插入？

Controller传递用户数据=> Repo创建UserEntity => Mapper => DB

将数组传递给UserRepository，将数组传递给映射器以获取新的UserEntity和插入？

Controller传递用户数据=> Repo传递用户数据=> Mapper创建UserEntity => DB

谁来负责管理对象的创建？

---

我知道这个问题很老，但我认为我会把我的想法放在这里，因为唯一的答案还没有被正式接受，这可能对未来的搜索者有帮助。 要直接回答你的问题，我会说以上都不是。 我更喜欢有额外的服务，如果您愿意的话，可以使用“经理”，以便管理控制器和回购/映射器对象之间的交互。 每个模型都有一个专门的管理器来处理它的创建，更新和删除。

控制器

我认为控制器是应用程序的粘合剂。 我们可以把所有我们想要的问题分解成尽可能多的部分，但是在某个地方，某些东西必须理解视图方面和模型方面，并且该对象是控制器。 话虽如此，我认为控制器应该很瘦，所以控制器唯一真正的工作就是将请求映射到响应。 任何类型的中间处理应该从其他地方启动。

在CRUD应用程序中，实现新对象并将其保存在控制器中很容易，即使它不止一次，因为它只需粘贴几行。 如果对象创作不平凡呢？ 我正在维护一个具有许多复杂关系的应用程序，用户提交的创建通常需要同时创建多个对象。 在仅用于控制器和模型的环境中进行维护是不可行的。

额外的服务层

为了解决这个问题，我创建了2个额外的服务层：FormHandler和Manager。 每次提交表单时，表单内容都会发送到表单处理程序层。 表单处理程序负责理解表单数据进入并对其进行规范化。 表单处理程序然后可以将数据传递给适当的管理器对象进行处理。 管理器对象处理数据并更新域图层。 他们负责创建模型，改变模型，并将其坚持到后端。

通过这种方式，控制器掌握了Request，Response，Form（可能，如果您的框架支持服务器端表单创建）和FormHandler。 表单处理程序具有表单（或表单数据）和经理的知识。 Manager具有知识库，映射器和模型的知识。 注意，现在，管理者是与Models和Mapper交互的唯一点，他们不知道表单数据或请求或响应。 另一方面，控制器和表单处理程序不需要知道域层数据或持久性。

结论

有了这个设计：

Controller -> FormHandler -> ModelManager -> Mapper

我发现我的所有类都是单元可测试的（即使控制器在某种程度上），因为分离出的关注点被很好地分离出来，单点交互对于避免重复逻辑是一个福音。

笔记

我脑海中的回购仅仅用于查询数据库 - 询问它是否有一些东西，而不是创建新的东西。

我在这种情况下的经验来自Symfony 2和Doctrine 2。

因人而异; 例如，您可能会发现表单层是不必要的，但我发现它非常方便从表单/视图数据到域模型理解的数据转换。

---

这是一个难以回答的问题。 由于几个原因，我的两分钱都在第一名。 首先，假设您的实体中有域验证，可以很好地拒绝正在传递的数据。 如果这种情况发生在2或3中，那么在拒绝之前你已经深入了几个物体。 就2/3和1之间的差异而言，它可能不是很多的内存或执行时间，但这是一个区别。 我试图快速失败。

其次，我认为控制器知道传入的数据以及对象是完全可以接受的。 我同意“高脂模型，瘦控制器”，但称该控制器无法了解实体正在控制器太瘦了 ，我喜欢。

链接地址: http://www.djcxy.com/p/10547.html

上一篇: Where to build new domain entities? Controller, repository, or mapper?

下一篇: remove ../ from path