c# asp.net datatable data-access-layer bll

c# - DAL y BLL en.NET



asp.net datatable (2)

Existe esta sugerencia de diseño DAL / BLL de Microsoft para las aplicaciones ASP.NET (2.0). Conozco algunas de las alternativas y he leído preguntas relacionadas aquí en SO. Sin embargo, me pregunto si vale la pena implementar esta solución propuesta hoy en día, ¿hay algún inconveniente específico que conozcas?

Quiero desarrollar componentes DAL / BLL para uso interno de la compañía, para acceder a datos de clientes y empleados, etc. de varias aplicaciones y scripts. Sin embargo, antes de comenzar a construir esas cosas, quiero estar seguro de que esta solución es ''buena''. Como ejemplo, el BLL pasa tablas de datos en lugar de encapsular cualquier cosa, no tiene objetos comerciales aislados que contengan lógica. Básicamente es solo una capa tonta que facilita un poco las operaciones de CRUD y permite el enlace de datos para los controles.

¿Podría alguien, que tiene experiencia en este campo, señalarme los pro y los contras de este enfoque?

pros:
- enfoque simple y parte del mapeo de datos se hace para usted con las tablas de datos.
- Ofrece algunas comodidades para activar las consultas Seleccionar, Agregar, Actualizar y Eliminar.
- podría ser adecuado para un diseño muy simple con pocas tablas.
- Adecuado para degings ER sin autorreferencia o ER con pocas tablas de búsqueda y simples / pocas combinaciones
- adecuado donde se requiere un almacén de datos simple. es decir. donde las ideas OO complejas deberían aplicarse a los "objetos comerciales", este patrón dificultaría las cosas.

contras:
- los modelos OO grandes tendrán problemas en este patrón
- Los diseños de ER complejos con muchas tablas, relaciones complejas o requisitos de objeto OO no se adaptarán a este patrón. las tablas de datos no brindan mucha asistencia para consultas de objetos en código como LINQ.
- la mayoría de las consultas deben escribirse a mano en SQL (esto incluye combinaciones). sí, puede usar el diseñador de consultas, pero esto no ayuda mucho.
- hay mucha duplicación de código en este enfoque. como escribirá muchos métodos CRUD en sus clases BLL (que también debe escribir desde cero).

conclusión: realmente depende de sus requisitos. si su implementación es pequeña / simple, esta podría ser una buena idea. pero crecer con una pequeña idea será difícil con este enfoque. un enfoque más OO lo configurará mucho mejor para la refactorización / expansión posterior. este patrón también es más antiguo / anticuado. consulta de objetos IQueryable / LINQ es más popular y se convertirá en un estándar más amplio en breve. Te sugiero que te subas a bordo de este vagón. también será mejor para su desarrollo personal a largo plazo. :RE

algunos enlaces:

Recomiendo totalmente NO USAR DATATABLES. Mire en una implementación de diseño impulsada por dominio que su marco de trabajo completo funcionará con objetos regulares que puede pasar a List <> o Queryable <>. Los DataTables son basura que ni siquiera deberían incluirse en .NET.

También recomendaría estudiar el uso de una infraestructura de Inyección / Inversión de Dependencia como Microsoft Unity o StructureMap para crear un código débilmente acoplado.