tags:

views:

73

answers:

2

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 to 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.

A: 

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.

Arnis L.
A: 

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.

devnull
That depends on what kind of architecture we are trying to follow. Domain driven design specifically aims to put business logic inside business objects.
Arnis L.