.NET y capas de base de datos

Question

Cuando trabajé por última vez en la programación, estábamos tratando de alejarnos del DataReaders y la API ADO.NET tradicional hacia Object Relational Mapping (ORM).

Para hacer esto, generamos un DataContext de nuestra base de datos a través de sqlmetal. Había entonces una delgada capa de datos que hacía el DataContextprivate, y cualquier código que necesitara acceder a la base de datos tendría que usar un método public en esta fina capa de datos. Estos métodos eran básicamente procedimientos almacenados; realizarían consultas en la base de datos a través de LINQ to SQL.

¿Es este un enfoque común hoy en día? Quiero decir, ¿todos los que utilizan el framework .NET 3.5 realmente ejecutan sqlmetal en su proceso de compilación, o qué? Casi parecía un truco en ese momento.

Básicamente, me gustaría saber si LINQ to SQL y sqlmetal es qué esperar si voy a escribir un DAL hoy en una tienda .NET 3.5 que no emplea un tercero, abierto fuente ORM.

Answer 1

Su enfoque es bueno. Actualmente uso los servicios de Astroria (ADO.NET Data Services). Hubo una buena introducción en MSDN Magazine sobre esto.

También me gusta el nuevo PLINQO (requiere CodeSmith Tools). Esto es muy astuto en mi opinión.

Cuando tengo una DAL (capa de servicio), solo consumo este servicio desde mi aplicación cliente (Silverlight o ASP.NET MVC).

Answer 2

Creo que depende de su uso, pero yo diría que con una capa de datos tan delgada como explicó que sería su DAL. La mayoría de los proyectos construirán otra capa encima de eso principalmente para editar/crear lógica y tal vez un poco de lógica de costura para obtener.

Para la mayoría de mis proyectos lo diseño así.

Repositorio mantiene la instancia de DataContext y expone algunos complemento básico/borrar métodos
ProductRepository: Repositorio expone consultas generales (IQueryable)
StoreService utiliza una instancia de diferentes repositorios como ProductRepository, SalesRepository y maneja toda la lógica para crear algo así como un producto.

Así que algo como ...

StoreService.CreateProduct(/* properites */) 

Esto volvería algún tipo de clase de resultado.

Answer 3

Todavía se considera la mejor práctica tener algún tipo de capa de acceso a datos. Si esto se logra mejor con un ORM es un tema muy debatido. Hay una facción que generalmente argumenta que los ORM son el camino a seguir. Otra facción argumenta que los procedimientos almacenados y la base de datos centrados es la mejor ruta.

Además, esto no puede ser exactamente el cartel que quería decir, pero similares (y también el de mi cubículo)

http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf

Answer 4

este mismo sitio utiliza LINQ a SQL, por lo tomo como usted será.

Oficialmente, Microsoft admite Entity Framework sobre LINQ to SQL en términos de nuevo desarrollo. Sin embargo, hay un grupo vocal de personas que piensan EF is the wrong way to go. LINQ to SQL seguirá existiendo por un tiempo, y es un ORM muy decente, aunque algo limitante en términos de qué back-end DB puede usar.

Recomendaría LINQ como un excelente punto de partida para su ORM. Si necesita algo mejor, consulte EF y/o NHibernate.

Answer 5

"¿Es este un enfoque común hoy? Quiero decir, ¿todos los que usan el framework .NET 3.5 realmente ejecutan sqlmetal en su proceso de compilación, o qué?"

Las personas que conozco que usan el Framework 3.5 (y eso es casi todo el mundo) - la gran mayoría - todavía usan NHibernate. La versión 2.0 es una muy bonita OR/M. Empecé a usarlo en un proyecto reciente y redujo significativamente mi código de acceso a datos, hasta el punto en que realmente no quiero usar nada más en el futuro. Y la API Fluent NHibernate está haciendo avances para las personas que no les gusta el mapeo XML.

Answer 6

La mejor capa de datos es la que es simple y completa y hace el trabajo sin ningún tipo de silbidos. He utilizado las tecnologías que mencionó y escribí sobre ellas aquí: The Only Pattern for Data Access is - There Are No Patterns for Data Access