Entity Framework y separación de capas

Estoy tratando de trabajar un poco con Entity Framework y recibí una pregunta sobre la separación de capas.

Usualmente uso el enfoque UI -> BLL -> DAL y me pregunto cómo usar EF aquí.

Mi DAL generalmente sería algo así como

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL:

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

Interfaz de usuario:

Person p = personBL.GetPerson(id)

Mi pregunta ahora es: dado que EF crea mi modelo y DAL, ¿es una buena idea envolver EF dentro de mi propio DAL o es solo una pérdida de tiempo?

Si no necesito envolver EF, ¿seguiría colocando mi Model.esmx dentro de su propia biblioteca de clases o estaría bien simplemente colocarlo dentro de mi BLL y trabajar allí?

Realmente no puedo ver la razón para envolver EF dentro de mi propio DAL, pero quiero saber qué están haciendo otras personas.

Entonces, en lugar de tener lo anterior, dejaría de lado el DAL y simplemente haría:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

¿Qué hacer?

El ejemplo que usted proporciona es una arquitectura en capas. Sé que se simplifica intencionalmente, pero:

Su capa de presentación está directamente vinculada a la entidad Persona. Esto está bien solo en los casos más simples, y definitivamente no cuando intentas definir tus capas.

El método GetPerson también está utilizando una práctica bastante mala de crear un nuevo contexto para cada llamada. Debería obtener el contexto en el constructor, y será proporcionado por su contenedor IOC.

Una estructura simple pero efectiva que he usado es:

• Project.Core: contiene modelos de vista e interfaces.
• Project.DAL: con mi EDMX y el código generado.
• Project.BLL - lógica de negocios.
• Project.Web: la aplicación web en sí.

Es importante observar que:

• Core no depende de ninguna otra solución.
• DAL no depende de ninguna otra solución.
• Project.Web depende de Core, pero no de DAL ni BLL.
• BLL depende de Core y DAL.

No necesita envolver su EDMX en nada.

Si puede prever la posibilidad de tener que cambiar de EF a algún otro enfoque, es posible que desee ampliar sus objetos de negocio (aprovechando las clases parciales) para implementar interfaces definidas en una capa de Business Object separada.

Luego, desde su código, solo tratará con esas interfaces y no con las clases concretas generadas. Es posible que se necesite un pequeño código de pegamento para mantener esto unido; que con el EDMX puede ser tu DAL.

Hay dos enfoques generales para las capas: capas estrictas y capas relajadas.

Un enfoque estrictamente estratificado restringe los componentes en una capa para interactuar solo con sus pares y con la capa directamente debajo.

Una aplicación relajada en capas afloja las restricciones de manera que un componente pueda interactuar con los componentes de cualquier capa inferior.

El uso de capas relajadas puede mejorar la eficiencia porque el sistema no tiene que reenviar llamadas simples de una capa a la siguiente. Por otro lado, el uso de capas relajadas no proporciona el mismo nivel de aislamiento entre las capas y hace que sea más difícil cambiar una capa inferior sin afectar las capas superiores.

Para soluciones grandes que involucran muchos componentes de software, es común tener una gran cantidad de componentes en el mismo nivel de abstracción que no son cohesivos. En este caso, cada capa puede descomponerse adicionalmente en uno o más subsistemas cohesivos. La figura 2 ilustra una posible notación de lenguaje de modelado unificado (UML) para representar capas que están compuestas de múltiples subsistemas.

conclusión: si no necesita la capa intermedia, piérdala; no todas las aplicaciones requieren el mismo enfoque y, de alguna manera, agregar una capa solo con el propósito de crear capas tendrá penalidades en el costo de la complejidad y el mantenimiento.