c# - presentación - Patrón de repositorio y/o/versus capa de lógica de negocios

mvc

Question

Tengo un problema. Quiero saber tu opinión.

Estoy tratando de usar el Patrón de repositorio. Tengo un objeto de repositorio que carga datos a un POCO. También he creado una capa de lógica de negocios que agrega un poco de funcionalidad pero básicamente envuelve el POCO. Así que al final tengo un BLL que carga DAO con el uso del repositorio.

No estoy muy contento con esta solución. Tengo tres capas, pero creo que BLL no proporciona suficiente funcionalidad para mantenerla allí. Por otro lado, ¿no quiero poner mi lógica en la capa de repositorio ni en la capa de acceso a datos?

Entonces mi pregunta es ¿dónde debería poner la lógica para la aplicación? ¿Qué solución usas (DAO + repo o DAO + BLL + rep o cualquier otra)?

Answer 1

Mi "DAL" (más de un ORM de cosecha propia, que es otro tema) es realmente un par de capas en sí mismo; una abstracción que proporciona repositorio y algún soporte de patrón de registro activo, y debajo está el código de acceso a datos real.

Tenemos una capa empresarial mínima en este punto, pero la verdadera razón es que es muy delgada, hay demasiada lógica empresarial (heredada) incrustada en los códigos subyacentes de la página web. A medida que se refactorice, espero que la capa de negocios crezca, crezca y crezca.

Esto es bastante estratificado estándar. No dices por qué no estás contento con tu stack actual, pero ten en cuenta que la razón principal para hacerlo es la separación de responsabilidades. También es posible que desee echar un vistazo a los conceptos del diseño impulsado por el dominio; proporciona mucha reflexión para organizar el código en torno a las políticas y prácticas comerciales, en lugar de cuestiones de software específicas. Es una herramienta analítica muy útil para tener en su caja de herramientas.

Answer 2

Hay dos formas básicas de pensar acerca de las reglas comerciales al diseñar su dominio.

1.) Las entidades de dominio son POCO / DTO básicos. Y los entrega a los servicios de dominio. Estos servicios podrían ser tan simples como otra clase, o realmente podrían ser servicios reales ubicados en otro servidor.

var user = repository.Find(x => x.UserName == userName);
if (userLogonService.IsValidUser(user, password)) {
   userLogonService.UpdateUserAsLoggedOn(user);
}
repository.SaveChanges();

2.) Las entidades de dominio contienen su propia lógica de operación. Esto está más cerca de lo que muchos patrones de MVC seguirán. Y ya que me preguntaste, este es el modelo que prefiero.

var user = repository.Find(x => x.UserName == userName);
if (user.CheckPassword(password)) {
    user.LogOnNow();
}
repository.SaveChanges();

Ambos son patrones completamente válidos. # 1 tiene un nivel discreto de operación comercial, pero sufre de un Modelo de dominio anémico . # 2 puede conducir a grandes entidades de dominio si su dominio comienza a ser complicado, o si un modelo puede hacer muchas cosas.

EDIT # 1: Respuesta a John Kraft

Oven.Bake (myPizza) vs. myPizza.Bake ()

En general estoy de acuerdo. ¿Tiene un solo servicio de horno o tiene docenas de hornos disponibles almacenados en un depósito de horno donde el horno es solo otra entidad de dominio? En el n. ° 2, el horno es parte del dominio. La forma en que suelo hacer modelos de dominio, la mayoría de los sustantivos son entidades de dominio , a menos que esté 100% seguro de que existe exactamente una cosa.

Pero algo le sucede a la pizza cuando está horneada.

interface ICanBeBaked {
    int BakeMinutes { get; }
    int BakeTemp { get; }
    void Bake();
}
class Pizza : ICanBeBaked {
    int BakeMinutes { get { return 15; } }
    int BakeTemp { get { return 425; } }
    void Bake() {
        // melt cheese!
        this.isBaked = true;
    }
}
class Oven {
    void Bake(ICanBeBaked thingToBake) {
        // set the temp, reserve this oven for the duration, etc.
        thingToBake.Bake();
    }
}