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

【问题标题】：Are business objects meant to have behaviour?业务对象是否意味着具有行为？
【发布时间】：2016-02-06 15:02:01
【问题描述】：

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

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

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

【问题讨论】：

标签： c# wcf enterprise

【解决方案1】：

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

【讨论】：