.net - sociedad - Diseño de objeto comercial DAL

objeto social de una sociedad anonima

Question

Al diseñar objetos comerciales, he intentado varios métodos diferentes para escribir la capa de acceso a datos. Algunos han funcionado mejor que otros, pero siempre he pensado que debe haber una "mejor" manera.

Realmente me gustaría ver las diferentes maneras en que las personas han manejado el DAL en diferentes situaciones y su opinión sobre cómo la técnica funcionó o no funcionó bien.

Answer 1

Depende mucho del código de artículo / muestra NHibernate Best Practices de Billy McCafferty para muchas aplicaciones Web / WinForms ahora. Es un artículo maravillosamente escrito que le proporcionará una buena arquitectura de muestra sólida, además de enseñarle NHibernate y TDD básicos. Él trata de darle una visión general de su arquitectura y decisiones de diseño.

Él crea un DAL muy elegante utilizando DataAccessObjects genéricos que puede ampliar para cada objeto de dominio, y está muy poco acoplado al BL utilizando interfaces y un DAOFactory. Yo recomendaría mirar primero la BasicSample, especialmente si no has trabajado antes con NHibernate.

Tenga en cuenta que este artículo se basa en gran medida en NHibernate, pero creo que el enfoque general podría ser fácilmente modificado para adaptarse a otros ORM.

Answer 2

Hay varios patrones comunes. El libro ''Los patrones de la arquitectura empresarial'' es una buena referencia para estos:

• Table Data Gateway
• Row Data Gateway
• Registro activo
• Data Mapper

Si usa un ORM, como llblgen, tiene la opción de autoservicio o adaptador.

Answer 3

Lamentablemente, no creo que haya una "mejor manera", es demasiado dependiente de la situación específica en cuanto al enfoque DAL que utiliza. Una gran discusión sobre el "estado del arte" es Patterns of Enterprise Application Architecture de Martin Fowler.

El Capítulo 10, Patrones arquitectónicos de origen de datos, habla específicamente sobre la mayoría de los patrones utilizados con mayor frecuencia para aplicaciones comerciales.

Sin embargo, en general, he encontrado que usar el enfoque más simple que cumpla con los requisitos básicos de mantenimiento y adaptabilidad es la mejor opción.

Por ejemplo, en un proyecto reciente, todo lo que necesitaba era un simple "Row Data Gateway". (Esto era simplemente clases generadas por código para cada tabla de base de datos relevante, incluidos los métodos para realizar las operaciones CRUD). No hubo debates interminables sobre ORM versus procesos almacenados, simplemente funcionó e hizo bien el trabajo requerido.

Answer 4

Si vas por la ruta NHibernate (un buen enlace al artículo por cierto de @Watson arriba), te recomiendo encarecidamente que consultes el proyecto de ejemplo suvius-flamingo de codebetter. Tiene un proyecto de muestra muy bueno, sucinto, que muestra a MVC y NHibernate en acción.

Aquí está el enlace suvius-flamingo .

Answer 5

Voy a suponer que quieres decir escribir un DAL que está accediendo a SQL, porque esta es la parte más común en la actualidad. UNO si los mayores problemas para escribir un DAL contra SQL es la parte ORM. Es decir, existe un desajuste de impedancia fundamental entre la programación de OO y los esquemas de bases de datos relacionales. Ha habido muchos grandes e incluso exitosos intentos de escribir ORM. Pero todos ellos sufren el mismo problema que es su beneficio: lo abstraen del SQL subyacente que se genera. Por qué esto es un problema, es que el rendimiento de su base de datos es un componente crítico de qué tan bien funciona su sistema en general. Muchos ORM (quizás la mayoría) no solo tienen un rendimiento inferior para muchas consultas estándar, sino que fomentan patrones de uso que degradarán considerablemente el rendimiento (cruzar relaciones repetidamente dentro de bucles al consultar colecciones es un ejemplo común, por lo que es difícil resolver bloqueos). otro). Por supuesto, después de aprender la API de ORM en detalle, generalmente puede encontrar formas de evitar estos baches de rendimiento.

Mi opinión actual sobre el estado de los ORM es que quiero que haga lo mínimo posible, al mismo tiempo que me proporciona las eficiencias de una biblioteca sólida que se ocupa de todos los aspectos prácticos del acceso a los datos. En otras palabras, debido a que no creo que todavía sean "lo suficientemente buenos", y puede que nunca sea SQL como el back-end, quiero mantener el control en el nivel básico, y voy a escribir SQL por Sin dudarlo, en muchos casos, sin importar el ORM, porque sé de qué manera específica quiero que se consulten los datos para mis necesidades.

Obviamente, este es un enfoque más frágil para la codificación que si usas religiosamente el ORM tal como estaba previsto, por lo que debes ser muy diligente en términos de pruebas unitarias, inyección SQL y separación adecuada de las preocupaciones. Entonces, para resumir, estoy de acuerdo con Ash, aunque eso no implica que él / ella esté de acuerdo conmigo :)

Answer 6

[actualizar] esto ya no es válido, se modificó el diseño de este proyecto [/ update]

En nuestro proyecto de código abierto Bunian, llegamos a la conclusión de que Business Objects (el componente completo) es el núcleo del sistema, y ​​todo debería girar en torno a él, incluida la capa de acceso a los datos.

El componente empresarial dictará a los demás lo que necesita, lo que implica que a través de itnerfaces. Por ejemplo, Business Object Person tendrá un miembro de interfaz llamado IRepositoryForPerson , a este miembro se le asignará una instancia a través del contenedor Dependency Injection cuando sea necesario.

Para más detalles, consulte la publicación de mi blog aquí:

http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//

y revisa el código de Bunian aquí (aunque todavía es amateur):

http://www.codeplex.com/Bunian

Por supuesto, habrá nuevas cosas emergentes con este enfoque, como el ciclo de vida de la sesión de acceso a datos (si está utilizando NHibernate, por ejemplo). pero eso sería para otra pregunta, supongo :)

Espero que encuentres esto útil