Linq a SQL y particionamiento lógico (DAL, BLL)

Question

Vamos a reconstruir uno de nuestros sitios en .Net. He leído muchos artículos y me gusta mucho la idea de separar nuestro proyecto en una capa de acceso a datos (DAL), capa de lógica empresarial (BLL) y capa de presentación (venimos de ASP clásico, por lo que este es un gran paso para nosotros) También me gusta mucho Linq a SQL.

Dado que Linq to SQL está dirigido a un desarrollo rápido, ¿es realmente posible con Linq a SQL tener un DAL, BLL y una capa de presentación? Con Linq a SQL, ¿el DAL devolvería las entidades o el código linq que posiblemente podría modificarse en el BLL? La relación entre DAL y BLL con Linq a SQL parece ser un tema difuso sin consenso, y dado que este es un gran salto para nosotros, definitivamente quiero tener un buen plan de juego antes de meterme en cualquier cosa.

Los conjuntos de datos mecanografiados parecen estar más equipados para esto, pero si logro algo similar con Linq iría por esa ruta.

Me gustaría mantenerme alejado de nHibernate y otras bibliotecas de terceros.

Answer 1

Estamos construyendo exactamente lo que describió, y estamos usando L2S para hacerlo. De acuerdo en que la relación entre el DAL y BLL es un poco confusa, pero tenemos un BLL distinto y un DAL distinto. Toda nuestra lógica está en el BLL y toda la recuperación/modificación de datos se realiza mediante llamadas al DAL (usando llamadas LINQ).

Nuestra aplicación no utiliza conjuntos de datos tipeados. Hemos construido clases de entidades para representar nuestros objetos. Ahora que he pasado un par de meses construyendo parte de esto, no nos veo (nosotros) nunca volviendo a los conjuntos de datos.

Además, no me quedaría colgado en L2S siendo "dirigido a un desarrollo rápido". Esto lo hace sonar como una herramienta de creación de prototipos. Estamos descubriendo que es una herramienta de fortaleza industrial. Esto podría ser contrario a lo que Microsoft podría estar diciendo al respecto, ya que prefieren que las personas usen EF.

Randy

Answer 2

recomiendo que dar un paso atrás y mirar a sus necesidades una vez más.

¿Necesita 3 niveles reales (es decir, la implementación física en diferentes máquinas) o simplemente particiones lógicas de su aplicación?

Hice exactamente este error en la primera gran aplicación que he escrito. Nunca necesité 3 niveles físicos (y nunca los necesitaré), pero diseñé la aplicación de esa manera. La consecuencia más llamativa fue que I Linq2Sql no admite desconectado Seguimiento de cambios en las entidades. Usé Linq2Sql Entity Base para solucionar esta limitación, sin embargo, viola muy mal el concepto de Ignorancia de persistencia (uno siempre sabe mejor después, ¿eh?).

Ir real n-tiers tiene muchas otras implicaciones en la arquitectura de aplicación.

Necesitará pasar mensajes, objetos de transferencia de datos, etc. Linq2SQL es un ORM decente, la estrecha integración con LINQ brinda posibilidades únicas. Otros ORM aún necesitarán tiempo para ponerse al día aquí. NHibernate 3.0 es una luz al final del túnel aquí. Linq2SQL es un gran ORM si tiene modelos de datos simples y puede asignar de una manera "clase por tabla".

Para el seguimiento de cambios desconectado (que necesitará si van n niveles) otros ORM tienen mejor soporte.

Y por último:

(que viene desde ASP clásico por lo que este es un paso muy importante para nosotros)

En estas circunstancias me gustaría ser especialmente cuidadoso. Las tecnologías de conmutación a menudo se subestiman. Incluso los programadores más inteligentes de su equipo tomarán decisiones equivocadas porque carecen de experiencia con la tecnología. No obstante, es importante buscar nuevas formas y mejorar tu conjunto de habilidades. Aquellos que nunca fallan nunca sucederán.

Answer 3

En mi humilde opinión, LINQ to SQL es la mejor opción disponible actualmente. Realmente hace que trabajar con datos sea sencillo y casi divertido. :-) Si está interesado en LINQ to SQL, eche un vistazo a nuestro proyecto PLINQO. Tiene algunas mejoras importantes para LINQ to SQL para que sea una mejor solución general.

Answer 4

yo diría L2S es el DAL. Lógica empresarial L2S + en clases separadas se convierte en un DAL + BLL combinado, el lado DAL es el tiempo de ejecución L2S y el código generado por L2S (datacontext, clases de entidad, etc.).

Aún puede separarlos fácilmente para que la parte generada por L2S y cualquier extensión de las entidades y el contexto de datos estén en una DLL separada, y la lógica de negocios adicional en un dll/servicio/etc. separado. Sin embargo, en muchos casos no hay una necesidad real de separarlos.

Una razón para separarse en DAL + BLL cuando usa L2S sería si prevé que pasará a otra tecnología de acceso a datos más adelante, o si está utilizando más de una tecnología de acceso a datos. Tener un DAL separado con cualquier elemento específico de L2S por separado debería facilitar el cambio del DAL. Si desea separar DAL + BLL por ese motivo, el L2S DAL-DLL debe exponer las clases de entidad, cualquier clase derivada o clase de proyección, y métodos para obtener entidades o colecciones (Lista, etc.), pero mantener el DataContext interno en el DAL clase para evitar que cosas específicas de L2S (consultas L2S, etc.) se filtren en el BLL.

JMHO.

---

Desde otros mencionados herramientas L2S, aquí está un resumen más completo de lo que está por ahí: http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

Creo que con LINQ el DAL y conceptos BLL ya no son significativos. Así que coloqué linq classes y algunos getters & setters en la carpeta 'Domain' debajo de la carpeta Code (parent). Luego creé las clases 'Repository' y 'FontEnd'.