Solución:
Los objetos comerciales son objetos que concentran toda la lógica de su aplicación. Utilice Business Objects para separar la lógica y los datos empresariales mediante un modelo de objetos.
SEE HERE
El DAO es responsable de obtener un objeto comercial de forma independiente del almacenamiento. Por ejemplo, puede crear un DAO para acceder a un cliente como
public interface CustomerDAO {
public Customer getCustomerById(Integer id)
}
y luego implementar un acceso a datos en jdbc
public class JdbcCustomerDao {
public Customer getCustomerById(Integer id){
DataSource dataSource ...;
Connection con = dataSource.getConnection(...);
}
}
o implementar un CustomerDao que acceda a un servicio web o lo que sea. La ventaja de CustomerDao es que un cliente (el código que utiliza CustomerDao) es independiente de la tecnología de almacenamiento concreta. Es por eso que debería diseñar la API DAO sin dependencias de almacenamiento. Una buena pista son las declaraciones de importación de la interfaz CustomerDAO. Si las declaraciones de importación de CustomerDAO contienen algo como:
import javax.sql.***
deberías reconsiderar el diseño de tu API. Pero tenga en cuenta que también puede introducir dependencias de API con cadenas. P.ej
public Customer findCustomer(String sqlWhereClause){
...
}
El objeto comercial contiene los datos y es el lugar donde debe colocar la lógica del dominio. Si está utilizando un enfoque de modelo de dominio enriquecido.
Para obtener más información, consulte Ejemplos concretos sobre por qué el ‘Modelo de dominio anémico’ se considera un antipatrón