LINQ: ¿en qué capa debería caer normalmente LINQ, DAL?

Question

solo quería reunir diferentes ideas y perspectivas sobre en qué capa debería (y por qué) caer LINQ?

Answer 1

depende de lo que quieras hacer con linq. Al usar linq2sql, recomiendo el DAL, pero Linq es más que solo acceso a la base de datos. puede usarlo para manipular listas, ienumerables de objetos comerciales, etc. Linq en sí mismo puede ser útil en cualquier parte de su aplicación.

Answer 2

LINQ = Idioma consultas integradas. Estas son las extensiones de consulta que le permiten consultar cualquier cosa, desde bases de datos a listas / colecciones a XML. El lenguaje de consulta es útil en cualquier capa.

Sin embargo, muchas personas se refieren a LINQ to SQL como simplemente " LINQ " En ese contexto, un BLL / DAL combinado tiene sentido cuando está utilizando L2S y ahí es donde hace las consultas LINQ contra su base de datos. Eso no excluye, por supuesto, hacer consultas posteriores contra los resultados de esas mismas consultas en consultas nuevas (Linq to object) en capas superiores ...

Answer 3

Considero su objeto derivado de DataContext en su propia capa DAL, y LINQ es solo una interfaz muy flexible para él. Por lo tanto, utilizo las consultas LINQ directamente en la capa empresarial.

Answer 4

Ambos. DataContext es el DAL y, al usar el diseñador, las clases parciales generadas automáticamente que se asignan a objetos SQL (tablas, vistas) pueden considerarse parte de su capa empresarial. Implemento clases parciales que implementan algunos de los métodos parciales para imponer la validación y la seguridad según sea necesario. Algunas reglas de negocios no se asignan directamente a objetos de base de datos y se manejan a través de otras clases.

Answer 5

Creo que si estás haciendo Linq a Sql, siempre debes hacerlo en tu DAL. Sin embargo, si está haciendo Linq to Objects donde solo está filtrando, jugar con un objeto diferente puede hacer que sea BL layer.

Answer 6

Creo que LINQ debería ser de muy bajo nivel (DAL) y creo que debería estar envuelto en un BLL.

Sé que a mucha gente le gusta usar la accesibilidad parcial de los modelos que genera LINQ to SQL, pero creo que debería tener una clara separación de intereses (¿qué hizo allí?). Creo que si va a tener una lógica de negocios, debe ser desacoplada completamente de su lógica de acceso a datos.

Creo que lo que lo hace complicado es el hecho de que puedes seguir encadenando esos métodos de extensión LINQ en cualquier lugar donde tengas una línea System.Linq usando tu código. Una vez más, creo que LINQ pertenece a la definición y debería estar en el nivel más bajo posible. También hace mucho más fácil la prueba TDD / Unit cuando envuelve el uso de LINQ en un BLL.

Answer 7

Uso linq en la tradicional 'capa de acceso a datos' o en 'objetos de acceso a datos'. Esto permite la modularización del código, promueve el código de datos en un solo lugar (en lugar de cortar y pegar el mismo código en algunos lugares diferentes) y permite desarrollar un extremo delantero diferente con relativa facilidad.

Answer 8

Depende de la arquitectura de su aplicación, y hace una gran diferencia en la medida en que el modelo de presentación coincide con el modelo de datos. Estoy de acuerdo con separar las operaciones de lógica de negocios de los objetos de datos y los métodos de acceso creados por LINQ. También tiendo a envolver todas las operaciones de nivel de datos dentro de una clase de administrador para que pueda hacer del contexto de datos una clase interna.

Answer 9

Creo que el punto de Linq es que reemplaza tu DAL.

El equivalente a tu DAL anterior es todo el código generado automáticamente en los archivos DBML + cualquier cosa extra que Linq no pueda agregar.