c# - POCO - 展平或使用复杂类型

Question

我在 ASP.Net MVC 项目中使用 POCO 作为我的模型类。到目前为止，它运行良好，但在大多数情况下，这些 POCO 包含简单类型。我现在的情况是，我正在考虑使用一些复杂的类型，但我不确定这种方法的好处。此外，由于我需要将单个数据库表拆分为多个 POCO，因此我的情况变得复杂。下面举例说明。我有一个包含大约 40 个字段的员工表。我不想总是传递这个具有所有属性的大对象，所以我创建了 3 个 POCO 类来表示数据的逻辑分组，如下所示:

public class EmployeeProfile
{
    public int EmployeeID { get; set; }
    public string FirstName { get; set; }        
    public string LastName { get; set; }
    public string Gender { get; set; }
    etc ...    
}

public class EmployeeContact
{
    public Address Address { get; set; }
    public PhoneNumber Phone { get; set; }        
    public string Email { get; set; }
}

public class EmploymentInfo
{
    public decimal Salary { get; set; }       
    public string Occupation { get; set; }
    etc ....
}

到目前为止一切顺利，但我有时也确实需要将整个员工表作为一个对象，这是我不确定的地方。我可以像这样通过将其他类型放入其中来创建员工类:

public class EmployeeDetail
{
    public EmployeeProfile EmployeeProfile { get; set; }
    public EmployeeContact EmployeeContact { get; set; }
    public EmploymentInfo EmploymentInfo { get; set; }        

}

或者我可以将三个 POCO 的所有属性(包括其中包含的复杂类型)的各个属性复制到 EmployeeDetail 类中，以便它是扁平的，具有如下简单属性:

public class EmployeeDetail
{
    public int EmployeeID { get; set; }
    public string FirstName { get; set; }        
    public string LastName { get; set; }
    public string Gender { get; set; }
    etc ...        
    public Address Address { get; set; }
    public PhoneNumber Phone { get; set; }        
    public string Email { get; set; }
    public decimal Salary { get; set; }       
    public string Occupation { get; set; }
    etc ....

}

除了包含复杂类型的版本将花费更短的时间来创建 POCO 之外，使用一种方法比使用另一种方法有什么好处？我认为重点是面向对象，但我不确定在这种情况下“嵌套”这些对象是否有任何好处。在我看来，访问嵌套对象并在我的 View 模型和领域模型之间来回转换它们需要做更多的工作。

编辑: 我想指出，我正在考虑的子模型并不特定于特定 View 。它们可能会在整个应用程序的多个地方使用。这是一个人力资源/员工福利应用程序。我需要这些类是可重用的，否则我会把它们放在我已经在使用的 ViewModel 中。

Answer 1

您实际上想要做的是将您的业务概念 Employee 分成 3 个部分，基于它们将被使用的 View 。所以你想将它拆分成 EmployeeProfile 以在与例如连接的 View 中显示它文件管理等

通过这样做，您将业务域与您的 View 域混合在一起 - 这是您应该避免的事情。

如果存在逻辑域拆分 + 很可能需要单独使用某些部分，则拆分域模型是一个很好的解决方案。因此，一个很好的例子可能是(尽管并非在所有情况下都是必要的)为 Employee 的 Address 定义一个单独的域模型。

如果我处在你的位置，我会怎么做:

• 我会留下一个域模型Employee，而不会将其拆分为与 View 相关的部分。
• 我会根据我在特定 View 上需要的 Employee 模型数据的哪一部分创建单独的 View 模型。
• 我会考虑是否可以将 Employee 模型拆分为一些与领域相关的子模型(例如，将 Address 与 Employee 分开)。

从性能的角度来看，上述解决方案也有好处。从数据库发送和向数据库发送几个额外的字段并不是什么大麻烦，而在需要整个子模型的情况下需要 JOIN 子模型在某些情况下可能会损害您的性能(特别是如果有数千名员工)。

此外:从可维护性的角度来看，我还建议使用上述解决方案。从领域的角度来看，如果使用太多嵌套对象并不合适，可能会带来一些额外的挑战，例如CRUD 操作(例如，在保存/更新整个 Employee 等时需要提供提交/回滚机制)。