0

我在 Pluralsight 上学习了一些关于清洁架构和领域驱动设计的课程。在等待 Eric Evan 关于 DDD 的书到来时，我遇到了以下情况和问题：

我正在建立一个新项目。我添加了以下项目：

  • 我的项目应用程序
  • 我的项目.Common
  • 我的项目.域
  • MyProject.Infrastructure
  • 我的项目持久性
  • 我的项目.WebApi

一个业务需求是让 WebApi 返回一个具有以下属性的模型：

  • 不符合我的命名约定；
  • 很丑。

该模型位于 MyProject.Application 项目中。例如：

namespace MyProject.Application
{
    public class MyModel
    {
        public string _communityname { set; get; }
        public List<string> photolist { set; get; }
        public string postedby { set; get; }
    }
}

通常我会在这些模型上应用 JsonPropery 属性以使其保持良好状态：

namespace MyProject.Application
{
    public class MyModel
    {
        [JsonProperty("_communityname")]
        public string CommunityName { set; get; }

        [JsonProperty("photolist")]
        public List<string> PhotoUrls { set; get; }

        [JsonProperty("postedby")]
        public string PostedBy { set; get; }
    }
}

但是，后来我想了想……对自己说：应用层不应该关心“事物”是如何呈现的。这是表示层的任务，在本例中为 WebApi。

这个对吗？应用程序层是否应该返回一个正常的模型并让 WebApi 将其转换/转换为业务所需的任何（丑陋的）表示形式。

提前谢谢了。

4

2 回答 2

0

我不确定 MyProject.Application 实际上做了什么？但我猜它不是你的 REST 端点，因为你有 MyProject.WebApi。

我会将其移至 WebApi 项目，因为它仅涉及向您的用户显示特定的数据格式。我会在 WebApi 项目中添加一个 Models 或 ViewModels 文件夹，并保留您通过 REST 端点公开的所有对象。并在控制器操作或 WebApi 项目中的服务中进行从域模型到“视图模型”的转换。关键之一是不要将域模型暴露给外界。

还可以查看 Eric Evans 的这段视频，了解自从他最初的 DDD 书籍出版以来他所学到的知识。https://www.infoq.com/presentations/ddd-eric-evans

这个问题可能比 StackOverflow更适合https://softwareengineering.stackexchange.com/ 。

于 2017-01-20T15:29:37.797 回答
0

如果您的 web api 是您的应用程序的唯一入口点，那么我认为在该项目中拥有您的 DTO 不会有什么坏处。通常，当您创建“应用程序服务”时，这些服务不一定仅由 api 使用，在这种情况下，您会重新思考整个事情。

归根结底，您的 READ MODEL (DTO) 只不过是您希望从“应用程序服务”返回的数据的投影。客户端可以是 Web api，也可以是需要使用该服务的任何其他进程。

是否有意义？

于 2017-01-20T19:09:04.353 回答