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

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

我把一个项目分成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）的业务对象，然后使用“业务逻辑层”来完成所有的验证/访问。e、 g.将我的EF对象转换为BO，映射属性并返回它

---

我应该如何进行这项工作？我想知道的是，我应该将业务逻辑放在业务对象中，还是应该将它们分为一个基本上是POCO的类和另一个执行所有访问/验证例程的类？

这是主观的，并且会根据您的需求而有所不同。只有POCO类的域对象被Martin fowler称为贫血域。DDD方法是将您的业务逻辑放在域对象中，但对于具有简单业务逻辑的应用程序来说，它可能无法补偿您在层间映射所需的额外复杂性。另一方面，有些人会争辩说，分割域对象和逻辑遵循单一责任原则