c# - Are business objects meant to have behaviour? -

i'm looking clarification here feel i'm duplicating code , potentially over-engineering project.

i've got project split 5 separate parts; front end client (wpf), wcf service , business logic dll, data access dll (using ef6) , database itself.

i found data transfer objects (dto's) (in service project) identical business objects (bo's) exception dtos have datamember/contact attributes.

so example, have dto , bo contact information this:

// 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; } } 

now i'm thinking business objects should contain methods validate state, instance:

internal bool validateemailaddress(ref string message) {     // validation logic here. } 

however lot of texts i've read far seem advocate having business object consists of properties (basically poco) , using 'business logic layer' validation/access. e.g. translating ef object bo, mapping properties , returning it.

how should proceed this? want know should putting business logic inside business objects or should separated 1 class poco , class access/validation routines?

this subjective , vary on requirements. having domain objects poco classes martin fowler calls anemic domain. ddd approach have business logic in domain objects app simple business logic perhaps doesn't pay off added complexity you'll need mappings between layers. on other hand argue splitting domain objects , logic follows single responsibility principle.