2

大家好，

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

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

我的想法是，新客户或新对手的创建总是会创建两条记录：一条记录​​在人员表中，一条记录在辅助表中。我在这背后的想法是，将有一个地方（人员表）来检查企业过去是否与给定人员进行过任何交互。

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

我在这里阅读了关于 1800 线控制器的帖子。我也读过这篇文章说你的服务层不应该知道视图模型，这让我认为它在控制器层中存在和死亡。如果服务层不接触视图模型，例如， （3）将和对象都返回给控制器是否是好的设计？workerServicePersonWorker

这是我的实体类：

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; }
    ...
}
4

1 回答 1

1

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

例如，我有一个 MVC 应用程序，它使用ASP.NET Membership.，但我也有一个自定义User表，我在其中存储诸如用户的名字或 OpenID 之类的东西。在同一个应用程序中，我有一个IAdminService可以处理有关用户管理的所有内容。返回到控制器的是一个 AdminUser 类，它看起来像
：IAdminService

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

MembershipUserWrapper只是默认值的包装器，MembershipUser以允许测试和更大的灵活性。

无论如何，您可能会争辩说这AdminUser实际上是一个视图模型，并且确实我确实有几个视图强类型为AdminUser. 仅仅因为它在“服务层”中而不让IAdminService返回一个不必要的复杂化问题，并且在这种情况下，AdminUser您不希望控制器每次都执行“转换” 。UserMembershipUserWrapperAdminUser

workerService 将 Person 和 Worker 对象都返回给 Controller 是否是好的设计？

我认为在这种情况下它可能是。您可以有两个独立的服务，但获取 aWorker和 aPerson的大部分逻辑可能是相同的，因此您将强迫自己重复大量代码或创建执行常见任务的第三个服务。

您应该注意适当的设计，但也要考虑KISS和YAGNI。现在做有意义的事情，并在需要时进行相应的重构。

于 2011-03-29T08:43:35.780 回答