Question

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

我将一个项目拆分为5个独立的部分;前端客户端（WPF），WCF服务，业务逻辑DLL，数据访问DLL（使用EF6）和数据库本身。

我发现我的数据传输对象（DTO＆＃39; s）（在服务项目中）几乎与我的业务对象（BO＆＃39; s）相同，但我的DTO具有DataMember / Contact属性。< / p>

例如，我有一个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的类和另一个执行所有访问/验证例程的类？

Answer 1

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

业务对象是否有行为？

1 个答案: