¿Qué factores deberían afectar la Capa de acceso a datos que uso en un nuevo proyecto?

Question

Estaré enseñando a un hijo de clase, y necesito explicar qué factores deben afectar su decisión sobre la tecnología de acceso a datos. Estoy familiarizado con muchos métodos de acceso a datos como los Conjuntos de datos escritos, Linq to SQL, Linq to Entities, .netTiers, LLBLGen y llamadas personalizadas con objetos de conexión SQL y comandos. Algunos de mis clientes solo permitirán el uso de procedimientos almacenados, y NO discutirán nada más. Algunos de mis clientes NO están listos para instalar .NET 3.5 todavía. Algunos clientes requieren un nivel de servicio web intermedio en cualquier aplicación web. La mayoría de las veces uso los Conjuntos de datos de tipos y los Servicios web personalizados, o uso .netTiers con CodeSmith. ¿En qué otra cosa debería estar pensando?

Answer 1

Al igual que con todas las opciones en un proyecto de software: depende ... Pero en mi opinión, el factor más importante es el entorno del proyecto.

Consiste en (no afirmo que esta lista esté completa de todos modos):

• Habilidades disponibles dentro del equipo de desarrollo Y el equipo de mantenimiento (si son diferentes)
• características requeridas
• Restricciones establecidas por los clientes (no todos los clientes admiten todas las tecnologías disponibles. Esto es algo que debe tener en cuenta al reemplazar de manera incremental un sistema heredado o al introducir un nuevo sistema en un entorno)
• Restricciones establecidas por la legislación

espero que esto te ayude.

Answer 2

Una cosa importante a recordar es que una base de datos no es necesariamente solo un almacén de datos de respaldo para una aplicación (de forma aislada). Otras aplicaciones y procesos podrían eventualmente requerir acceso a la base de datos, especialmente en bases de datos (o aplicaciones) grandes o "empresariales" y, sobre todo, con suficiente tiempo.

Es importante tener en cuenta:

ETL / Loads / Migration

Integración / sincronización externa (BizTalk / SSIS)

Reutilización por otras aplicaciones (especialmente sitios web, aplicaciones móviles, etc.)

Superficie de seguridad / ataque (¿es un enfoque menos seguro que otro?)

Tareas de mantenimiento

Disponibilidad: ¿la base de datos estará en uso 24/7? ¿Un enfoque va a proporcionar una mejor disponibilidad que otro, etc.

Además, algunas consideraciones de diseño están en orden. ¿Estás sintonizando para selecciones más rápidas, o escrituras más rápidas? Un diseño de acceso a datos podría funcionar mejor que otro.

No estoy afirmando que haya una sola bala de plata, pero lo que hago es advertir que cualquier patrón de diseño de acceso a datos requiere un pensamiento de "visión general": ¿abordará las preocupaciones de hoy y lo que razonablemente puede predecir que podrían ser las necesidades de mañana? ?

Además, ¿proporcionará una API externa o algún marco para un acceso consistente a los datos? ¿Se expondrá directa o indirectamente?

Creo que hay un lugar para Entity Framework / LINQ to SQL, los procedimientos almacenados tradicionales y otras herramientas como NHibernate (etc.), pero debe justificar y racionalizar la elección de la tecnología primero y tratar de asegurarse de que sea así. apropiado para las necesidades presentes y futuras.

EDITAR: Lo siento, olvidé el grande: la capacidad de mantenimiento. Algunas de las soluciones basadas en plantillas le ofrecen algunas ganancias decentes al poder regenerar un DAL después de los cambios de esquema, sobre otras (como los procedimientos almacenados escritos a mano). Vale la pena sopesar las ganancias de productividad frente a las desventajas.

Answer 3

Creo que entre tu publicación original y las adiciones de norbertB has cubierto casi todo. Comience con las restricciones absolutas (y recuerde que solo porque un cliente diga no a algo una vez, incluso si dicen que es absoluto, eso no significa que no pueda ayudar a cambiar de opinión ...). Una vez que haya reducido el campo con las restricciones absolutas, observe las otras cosas.

Una cosa que pareció quedar fuera fue la flexibilidad. Por ejemplo, si estuviera tratando de elegir entre dos tecnologías similares y supiera que una podía admitir vistas actualizables y la otra no, incluso si no tuviera ninguna necesidad de vistas actualizables en el momento en que todavía me inclinaría hacia esa. ; por si acaso " ;.

Answer 4

Realmente solo estoy pensando en dos cosas. La primera es si voy a tener tantos datos que cualquier otra cosa importa. Si no está colocando millones de filas en las tablas, es probable que no importe qué tecnología vaya a utilizar porque todas funcionarán lo suficientemente rápido.

La segunda cosa es si puedo usar LINQ, porque me parece que usar LINQ (a SQL, a Entities, a LLBLGen, no importa) para consultar la base de datos le da dos cosas importantes. La primera es que es muy fácil escribir consultas y, en segundo lugar, es moderadamente fácil cambiar entre dos marcos que necesitan LINQ, en caso de que cambien los requisitos.