对于业务数据具有 1 到 0..1 关系的服务层设计，最佳实践是什么？

Question

大家好，

我研究并发现了一些关于设计 MVC 服务层的讨论，但我还没有找到我的确切问题的答案。关于服务层相互依赖的帖子有一张图片说明了我的想法，但我还有一个问题我不认为引用的帖子中涵盖了这一点。

我的应用程序将跟踪在多种环境中与人类交互的非营利组织的数据。也许这个人是客户，也许他们是顾问，或者也许他们是对手。它们可以是多个。客户后来可能会成为对手（想想律师的客户）。

我的想法是，创建新客户或新对手总是会创建两条记录：人员表中的 1 条记录和辅助表中的 1 条记录。我的想法是，将有一个地方（人员表）来检查企业过去是否与特定人员有过任何互动。

我的问题是，当以 1 到 0..1 的关系表示与控制器层的实体时，(1) 在将类传递给视图之前，控制器是否应该参与组合和拆分类？ （2）如果没有，服务层是否应该构建viewmodel？

我读过关于1800行Controller的帖子此处。 我还阅读了 这篇文章< /a> 这表示你的服务层不应该了解视图模型，这让我认为它在控制器层中生死存亡。如果服务层不接触视图模型，例如，(3) 让 workerService 返回 Person 和 Worker 是否是一个好的设计 对象到控制器？

这是我的实体类：

public class Record
{
    public DateTime datecreated { get; set; }
    public DateTime dateupdated { get; set; }
    public string Createdby { get; set; }
    public string Updatedby { get; set; }
}

public class Person : Record
{   
    public int ID { get; set; }
    public virtual Worker Worker { get; set; }
    publiv virtual Defendant defendant {get; set;}
    ...
}

public class Worker : Record
{
    public int ID { get; set; }
    public virtual Person person { get; set; }
    ...
}

public class Defendant : Record
{
    public int ID { get; set; }
    public virtual Person person { get; set; }
    ...
} 

Answer 1

我认为您应该尝试在“好的设计”和适合您的设计之间找到平衡。

例如，我有一个使用 ASP.NET Membership 的 MVC 应用程序，但我还有一个自定义的 User 表，我在其中存储用户的友好名称或 OpenID 等内容。在同一个应用程序中，我有一个 IAdminService 来处理与用户管理有关的所有事情。
IAdminService 返回到控制器的是一个 AdminUser 类，它看起来像：

public class AdminUser
{
    public string UserName { get; set; }
    public User User { get; set; }
    public MembershipUserWrapper MembershipUser { get; set; }
}

MembershipUserWrapper 只是默认 MembershipUser 的包装器，以允许测试和总体而言更加灵活。

不管怎样，你可能会说 AdminUser 实际上是一个视图模型，而且我确实有几个强类型化为 AdminUser 的视图。如果不让 IAdminService 返回 AdminUser 仅仅因为它位于“服务层”，那么事情就会变得不必要地复杂化，在这种情况下，您不需要控制器每次都执行从 User 和 MembershipUserWrapper 到 AdminUser 的“转换”。

workerService 将 Person 和 Worker 对象返回给 Controller 是一个好的设计吗？

我认为在这种情况下可能是好的。您可以有两个单独的服务，但获取 Worker 和 Person 的大部分逻辑可能是相同的，因此您会强迫自己要么重复很多次代码或创建执行常见任务的第三个服务。

你应该注意正确的设计，但也要注意 KISS 和 YAGNI 纳入考虑范围。现在就做有意义的事情，并在需要时进行相应的重构。