Mejores prácticas: arquitectura de 3 niveles en LINQ

Question

Estoy trabajando en un proyecto personal (C # / ASP.NET) que usará LINQ to SQL. La solución tendrá (hasta ahora) un proyecto de formulario web, un proyecto de espacio de nombres (lógica de negocios) y un proyecto de pruebas. Estoy en las primeras etapas hasta ahora (claramente en la fase de diseño).

¿Hay un paradigma para la arquitectura de 3 niveles aquí? Parece que el DAL es completamente inútil en este caso; parece que debería realizar la consulta LINQ directamente desde la lógica empresarial.

También se me ocurre que si solo mantengo un DataContext residente y lo paso, solo necesitaría una conexión abierta. Esto tendría el beneficio adicional de confirmar los cambios de una vez en lugar de granular. ¿Alguna idea sobre eso?

Encontré este hilo , pero Parece pintar una imagen incompleta. ¿Hay algún artículo en profundidad sobre el tema?

Answer 1

Puede pensar en LINQ-to-SQL como su DAL, por lo que debe usarlo & "; directamente desde la lógica de negocios &"; no es necesariamente algo malo.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx tiene algunos enfoques populares de L2S listados .

En nuestro proyecto, no queríamos pasar el contexto de datos, por lo que utilizamos un patrón similar al # 3 del enlace anterior (Contexto de datos ambientales, ver más abajo). Tuvo algunos problemas, pero funcionó razonablemente bien; al menos para nuestro proyecto web.

  

Contexto de datos ambientales (actualmente usando esto)

     

La idea detrás del ambiente de datacontext es que el contexto se crea para un hilo particular o un httpcontext (en asp.net) tan pronto como haya una primera llamada para el DataContext. Luego, se utiliza el mismo contexto para ese hilo o solicitud a menos que se elimine manualmente. Esto se hace almacenando el contexto en el almacén de datos de solicitud / subproceso. El enfoque de este patrón es similar al DataContext estático, sin embargo, se proporciona separación para cada hilo y solicitudes. Esto funciona muy bien en Asp.Net, sin embargo, nuevamente está plagado de algunos de los problemas del contexto estático.

     

Problemas con este patrón:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

Podrías leer un poco sobre el diseño impulsado por dominio.

Con la práctica del diseño controlado por dominio (DDD), tiene un rico 'modelo de dominio', en el que expresa el dominio del problema que desea abordar. Este modelo de dominio consta de clases (y estructuras) con las que modela sus entidades comerciales. El modelo de dominio también consta de repositorios.
Un repositorio es algún tipo de abstracción que utiliza en su modelo de dominio (y en su aplicación); El repositorio es una abstracción de su almacén de datos. A través del repositorio, puede recuperar entidades, y puede usar el repositorio para persistir entidades.

En su caso, sus repositorios podrían usar Linq To SQL internamente para comunicarse con la base de datos. Sin embargo, tenga en cuenta que su repositorio no debe ser responsable de administrar (abrir / cerrar) la conexión y la transacción (inicio / confirmación / reversión). Por qué ? - > porque el repositorio no tiene conocimiento o noción del contexto en el que se usa. Es su aplicación o capa de servicio (la capa que utiliza su modelo de dominio y, por lo tanto, su repositorio) la responsable de abrir una nueva conexión e iniciar / confirmar transacciones. (O, en su caso, abra un nuevo DataContext). Luego puede pasar el DataContext al repositorio.

(Eric Evans tiene un gran libro sobre DDD, aunque sea un hueso duro de roer, de vez en cuando).

Answer 3

Debe tener cuidado con su terminología. Cuando dices LINQ te refieres a Linq-to-sql y cuando dices 3 niveles, eso generalmente significa que estás hablando de un escenario de implementación con 3 máquinas separadas. No estoy seguro de si eso es lo que quieres decir.

Una arquitectura de tres capas sigue siendo una buena idea cuando se utiliza una herramienta ORM como linq-to-sql. El DAL se convierte en un lugar para almacenar su lógica de consulta. Es una buena idea sacar sus consultas de su capa empresarial porque las consultas son una preocupación de persistencia, no una preocupación de lógica de negocios.

La técnica habitual para administrar el contexto de datos es tener un solo contexto de datos por solicitud.

En términos de otros artículos sobre el tema, puede consultar cualquier guía de arquitectura para cualquier herramienta ORM: linq-to-sql no es diferente. Busque artículos sobre arquitectura para NHibernate.

Answer 4

La biblioteca LINQ to SQL es su DAL en este caso, y en lugar de hacer llamadas API tradicionales desde su capa empresarial (por ejemplo, DAL.GetObjectById (id)) tiene la flexibilidad de solicitudes mucho más expresivas en el DAL.

Si tuviera otras necesidades, por ejemplo, su propio proveedor LINQ que se conecta a un respaldo de datos que no sea MSSQL, entonces implementaría su propio DAL.

Además, con respecto al DataContext, no se recomienda usar un patrón singleton con " un DataContext residente " ;. Un objeto DataContext debe representar una única transacción lógica, lo que sea que eso signifique para su aplicación. (Parafraseado de http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx )