DAL y BLL en .NET

Question

Existe esta sugerencia de diseño DAL / BLL de Microsoft para ASP Aplicaciones .NET (2.0). Conozco algunas de las alternativas y he leído preguntas relacionadas aquí sobre 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 conozca?

Deseo desarrollar componentes DAL / BLL para uso interno de la compañía, para acceder a datos de clientes y empleados, etc. desde 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, usted no ' Tiene objetos comerciales aislados que contienen lógica. Básicamente es solo una capa tonta que facilita un poco las operaciones CRUD y permite la vinculación de datos para los controles.

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

Answer 1

pros:
: enfoque simple y parte de la asignación de datos se realiza por usted con la tabla de datos.
: ofrece algunas comodidades para disparar consultas de Seleccionar, Agregar, Actualizar y Eliminar.
: puede ser adecuado para un diseño muy simple con pocas tablas.
: adecuado para diseños de ER sin autorreferencia o ER con pocas tablas de búsqueda y uniones simples / pocas
: adecuado donde se requiere un almacén de datos simple. es decir. donde las ideas complejas de OO deben aplicarse a " objetos de negocio " este patrón haría las cosas más difíciles.

contras:
- los grandes modelos OO tendrán dificultades en este patrón
: los diseños complejos de ER con muchas tablas, relaciones complejas o requisitos de objetos OO no se ajustarán a este patrón. las tablas de datos no brindan mucha ayuda para las consultas de objetos en código como LINQ.
: la mayoría de las consultas deben escribirse a mano en SQL (esto incluye uniones). sí, puede usar el diseñador de consultas, pero esto no ayuda mucho.
- hay mucha duplicación de código en este enfoque. ya que escribirás muchos métodos CRUD en tus clases de BLL (que también debes 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 idea pequeña será difícil con este enfoque. un enfoque más OO lo preparará mucho mejor para refactorizar / expandir más tarde. Este patrón también es más antiguo / anticuado. La 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 este vagón. Será mejor para su desarrollo personal a largo plazo también. : D

algunos enlaces:

• pruebe aspnet MVC - http: // www. asp.net/learn/mvc-videos/video-360.aspx?redir=true
• http://www.asp.net/ learn / mvc-videos / video-361.aspx? redir = true
• http://www.asp.net/learn/mvc- videos / video-395.aspx
• si su alcance es mayor, este será un buen comienzo con patrones útiles: http://www.asp.net/learn/mvc-videos/video-350.aspx

Answer 2

Recomiendo NO USAR DATATABLES. Busque en una implementación de diseño impulsada por el dominio que su marco completo funcionará con objetos regulares que puede pasar a List & Lt; & Gt; o Consultable < > ;. Las tablas de datos son basura que ya ni siquiera deberían incluirse en .NET.

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