POCO Best Practice

All, I have a series of domain objects (project is NHibernate based). Currently as per 'good practice' they define only the business objects, comprising properties and methods specific to each objects function within the domain. However one of the objects has a requirement to send an SMTP message. I have a simple SMTP client class defined in a separate 'Utilities' assembly. In order to use this mail client from within the POCO, I would need 开发者_如何学JAVAto hold a reference to the utilities assembly in the domain. My query is this... Is it a departure from best practice to hold such a reference in a POCO, for the purpose of gaining necessary business functionality.

Kind Regards

Paul J.

Code against abstraction and use dependency injection in order to avoid reference.

public class PocoObject{
    public PocoObject(IMailSender mailSender){
      _mailSender=mailSender;          
    }

    public void DoStuff(){
      mailSender.Send(to,content,blabla);
    }
}

But mail sending kind a doesn't fit into Domain. It seems more like application service.

It is. Sending a SMTP message sounds more like a business rule rather than a business object responsibility. Your business object is a POCO, which in most of the cases implies only data and no behavior. As Arnis L. mentioned it's better to have a service in your system that manages the message sending job.