¿Es el doble de trabajo creando un componente de acceso a datos y componentes de negocio?

Question

Estoy diseñando mi primera aplicación en capas que consiste en una Datos, Negocio, y una capa de presentación.

Mis componentes de negocio (por ejemplo, Business.Components.UserComponent) tiene actualmente el método siguiente:

public void Create(User entity)
{
    using (DataContext ctx = new DataContext())
    {
        ctx.Users.AddObject(entity);
        ctx.SaveChanges();
    }
}

Me gusta este diseño. Sin embargo, me he encontrado con algunos ejemplos en línea que recomendarían la siguiente implementación:

public void Create(User entity)
{
    // Instanciate the User Data Access Component
    UserDAC dac = new UserDAC();
    dac.InsertUser(entity);
}

Esto daría lugar a la creación de un componente de acceso a datos para todas las entidades, cada una conteniendo los métodos básicos (crear, editar, borrar, etc ...).

Esto parece ser doble trabajo, ya que tendría que crear el componente de acceso a datos con los métodos básicos, así como los componentes de negocio que simplemente llama a los métodos en el componente de acceso a datos.

¿Qué se considera una recomendación para la correcta realización de las funcionalidades básicas CRUD en una aplicación en capas? Deben ser 'codificado' en el Componente de negocio o en un Data Access Component?

Answer 1

Depende. Si usted espera que su capa de negocio, simplemente hacer las operaciones CRUD que usted puede seguir su planteamiento inicial. Si va a utilizar un poco de lógica de negocio grande donde componente de negocio trabajará con muchas entidades segundo enfoque es mejor.

Por lo que la gente le gusta utilizar segundo enfoque está poniendo a prueba la ignorancia y persistencia. Si utiliza el primer método de componentes de negocio está estrechamente unida con el marco de la entidad. El imitar ObjectContext no es una tarea muy fácil, así que la prueba es dura. Si utiliza la segunda acerque a su capa de negocio es independiente de la capa de persistencia. Usted puede probar fácilmente e incluso se puede cambiar persistencia capa si es necesario. Pero esos son conceptos más avanzados que probablemente no está buscando en este momento. Su código se necesita alguna mejora adicional para ser comprobable.

DAC puede ser también implementado como repositorio. Hay un montón de maneras de cómo crear repositorio genérico para que tenga una sola clase y que definen el tipo de entidad al generar ejemplares de repositorio:

var repository = new GenericRepository<User>();

También ten en cuenta que el uso de la capa de acceso de datos por separado introduce una nueva complejidad, porque a veces es razonable compartir solo contexto entre múltiples repositorios. Esto viene junto con algo conocido como Unidad de patrón de trabajo.

Hay un montón de artículos sobre la implementación del repositorio y la Unidad de patrones de trabajo en Internet. algunos de ellos he guardado como favoritos en casa así que si usted está interesado puedo incluirlos a mi respuesta más adelante.