业务对象是否意味着具有行为？

Question

我只是想在这里寻求澄清，因为我觉得我基本上是在复制代码并可能过度设计我的项目。

我将一个项目分成了 5 个独立的部分；前端客户端 (WPF)、WCF 服务、业务逻辑 DLL、数据访问 DLL（使用 EF6）和数据库本身。

我发现我的数据传输对象 (DTO)（在服务项目中）几乎与我的业务对象 (BO) 相同，只是我的 DTO 具有 DataMember/Contact 属性。

例如，我有一个 DTO 和 BO 的联系信息，如下所示：

// ContactInformationDto.cs
[DataContract]
public class ContactInformationDto
{
    [DataMember]
    public string AddressLine1 { get; set; }
    [DataMember]
    public string AddressLine2 { get; set; }
    [DataMember]
    public string AddressLine3 { get; set; }
    [DataMember]
    public string Postcode { get; set; }
    [DataMember]
    public string PhoneNumber { get; set; }
    [DataMember]
    public string EmailAddress { get; set; }
}

// ContactInformationBo.cs
public class ContactInformationBo
{
    public int PersonID { get; set; }
    public string AddressLine1 { get; set; }
    public string AddressLine2 { get; set; }
    public string AddressLine3 { get; set; }
    public string Postcode { get; set; }
    public string PhoneNumber { get; set; }
    public string EmailAddress { get; set; }
}

现在我认为业务对象应该包含验证其状态的方法，例如：

internal bool ValidateEmailAddress(ref string message)
{
    // Validation logic here.
}

然而，到目前为止我读过的很多文本似乎都提倡拥有一个仅由属性组成的业务对象（基本上是一个 POCO），然后使用 'business logic layer' 来完成所有 validation/access.例如将我的 EF 对象转换为 BO，映射属性并将其返回。

我该如何处理？我想知道的是我应该将我的业务逻辑放在业务对象中还是应该将它们分成一个 class 本质上是一个 POCO 和另一个 class 它执行所有 access/validation 例程？

Answer 1

这是主观的，会因您的要求而异。只有 POCO 类的领域对象就是 Martin fowler 所说的贫血领域。 DDD 方法是将您的业务逻辑放在域对象中，但对于具有简单业务逻辑的应用程序，它可能无法抵消层之间映射所需的额外复杂性。另一方面，有些人会争论拆分域对象和逻辑遵循单一职责原则。

业务对象是否意味着具有行为？

Are business objects meant to have behaviour?

c#

wcf

enterprise