tier software programming net multi asp oop n-tier business-logic-layer

oop - software - tier server



Nunca he encontrado una capa empresarial bien escrita. ¿Algún consejo? (9)

Nunca he encontrado una capa empresarial bien escrita.

Aquí está la opinión de Alex Papadimoulis sobre esto :

[...] Si lo piensas, prácticamente cada línea de código en una aplicación de software es lógica de negocios:

  • La tabla de la base de datos de clientes, con sus columnas CustomerNumber (CHAR-13), ApprovedDate (DATETIME) y SalesRepName (VARCHAR-35): lógica comercial. Si no fuera así, simplemente sería Table032 con Column01, Column02 y Column03.
  • La subrutina que extiende un descuento del diez por ciento a clientes nuevos: definitivamente lógica comercial. Y con suerte, no codificado.
  • Y el código que destaca las facturas vencidas en rojo: eso también es lógica de negocios. Internet Explorer ciertamente no busca las cuerdas "sin pagar" y "más de 30 días" e ir, oye, eso seguro se vería bien con un fondo # 990000!

Entonces, ¿cómo es posible encapsular toda esta lógica empresarial en una sola capa de código? ¡Con una arquitectura terrible y un código malo, por supuesto!

[...] Al implicar que la arquitectura de un sistema debe incluir una capa dedicada a la lógica comercial, muchos desarrolladores emplean todo tipo de técnicas horriblemente ingeniosas para lograr ese objetivo. Y siempre termina en un desastre.

Miro a mi alrededor y veo algunos fragmentos de código geniales para definir reglas, validación, objetos comerciales (entidades) y cosas por el estilo, pero debo admitir que nunca he visto una capa empresarial excelente y bien escrita en su totalidad.

Me quedé sabiendo lo que no me gusta, pero sin saber qué tan bueno es.

¿Alguien puede señalar algunas buenas capas comerciales de OO (u objetos de gran negocio) o dejarme saber cómo juzgan una capa de negocios y qué hace que una sea excelente?

Gracias

Fue útil para mí aprender y jugar con CSLA.Net (si eres un chico de MS). Nunca he implementado una aplicación CSLA "pura", pero he utilizado muchas de las ideas presentadas en la arquitectura.

Su mejor apuesta es seguir buscando esa elusiva bala mágica y usar las ideas que mejor se adapten al problema que está resolviendo. Mantenlo simple.

Imagino que esto se debe a que la lógica empresarial, como regla general, es arbitraria y desagradable. Basura dentro basura fuera.

Además, la mayoría de las capas de negocios realmente buenas son muy probablemente propiedad. ;-)

Posiblemente porque en realidad nunca somos capaces de desacoplar por completo la lógica de negocios del "proceso", las entradas, los resultados, la interfaz y, en última instancia, a las personas les resulta difícil lidiar con el resumen y mucho menos relacionarlo con la realidad.

Un problema que encuentro es que incluso cuando se tiene una capa empresarial bien diseñada, es difícil evitar que la lógica de negocios se filtre, y las herramientas de desarrollo tienden a fomentar esto. Por ejemplo, tan pronto como agrega un control de validador a un ASP.NET WebForm, deja que la lógica de negocios se filtre a la vista. La validación debe ocurrir en la capa de negocios y solo los resultados se muestran en la vista. Y tan pronto como agrega restricciones a una base de datos, también tiene lógica comercial en su base de datos. Sin embargo, los tipos de DBA tienden a estar en desacuerdo con este último punto.

Se han diseñado buenas capas de negocios después de un análisis exhaustivo de dominio. Si puede capturar la semántica de la empresa y aislarla de cualquier tipo de implementación, ya sea en el almacenamiento de datos o en cualquier aplicación específica (incluida la presentación), entonces la lógica debe ser bien factorizada y reutilizable en diferentes contextos.

Así como un buen diseño de esquema de base de datos debe capturar la semántica empresarial y aislarse de cualquier aplicación, una capa empresarial debería hacer lo mismo e incluso si un esquema de base de datos y una capa de negocio describen las mismas entidades y conceptos, los dos deberían ser utilizables en contextos separados - un esquema de base de datos no debería tener que cambiar incluso cuando la lógica de negocios cambie a menos que el esquema no refleje el negocio actual. Una capa empresarial debería funcionar con cualquier esquema de almacenamiento siempre que se abstraiga a través de una capa intermedia. Por ejemplo, el marco Entity de ADO.NET le permite diseñar un esquema conceptual que se correlaciona con la capa empresarial y tiene una asignación separada al esquema de almacenamiento que se puede cambiar sin recompilar la capa de objeto de negocio o la capa conceptual.

Si una persona desde el punto de vista comercial puede ver el código escrito con la capa de negocios y tener una idea aproximada de lo que está sucediendo, entonces podría ser una buena indicación de que los objetos fueron diseñados correctamente: usted ha transmitido con éxito una solución en el dominio del problema sin ofuscarlo con artefactos del dominio de la solución.

Siempre he estado atrapado entre una roca y un lugar difícil. Idealmente, su lógica comercial no estaría relacionada en absoluto con la base de datos o problemas relacionados con la interfaz de usuario.

Las llaves causan problemas Aún así, encuentro que cosas como llaves principales y externas causan problemas. Incluso herramientas como Entity Framework no eliminan completamente este creep. Puede ser extremadamente ineficiente convertir los ID pasados ​​como datos POST en sus respectivos objetos, solo para pasarlos a la capa de negocios, que luego los pasa a la capa de datos para ser eliminados nuevamente.

Incluso las bases de datos NoSQL vienen con problemas. Tienden a devolver modelos de objetos completos, pero generalmente devuelven más de lo que necesita y pueden generar problemas porque supone que el modelo de objetos no cambiará. Y las claves todavía se encuentran en las bases de datos NoSQL.

Reutilización contra gastos generales También está la cuestión de la reutilización de códigos. Es bastante común que las capas de datos devuelvan objetos completamente poblados, incluidas todas las columnas de esa tabla o tablas en particular. Sin embargo, a menudo la lógica empresarial solo se preocupa por un subconjunto limitado de esta información. Se presta a objetos de transferencia de datos especializados que solo llevan consigo los datos relavent. Por supuesto, necesita convertir representaciones, por lo que crea una clase mapeador. Luego, cuando guardas, necesitas convertir de alguna manera estos objetos menores en la representación de la base de datos completa o realizar una ACTUALIZACIÓN parcial (es decir, otro comando SQL).

Entonces, veo una gran cantidad de clases de capa de negocios que aceptan objetos mapeando directamente a las tablas de la base de datos (objetos de transferencia de datos). También veo una gran cantidad de capas de negocios que aceptan valores UI sin formato (objetos de presentación), también. Tampoco es inusual ver capas de negocios llamando a la base de datos a mediados de computación para recuperar los datos necesarios. Intentar tomarlo por adelantado probablemente sería ineficiente (piense en cómo y en que sentencia puede afectar los datos que se recuperan) y los valores cargados de latencia resultan en una gran cantidad de llamadas mágicas o no intencionadas a la base de datos.

Escribe tu lógica primero Recientemente, he estado tratando de escribir el código "central" primero. Este es el código que realiza la lógica de negocio real. No sé ustedes, pero muchas veces cuando repaso el código de otra persona, les hago la pregunta: "¿Pero dónde está [la regla del negocio]?" A menudo, la lógica empresarial está tan llena de preocupaciones sobre cómo tomar datos, transformarlos y otras cosas que ni siquiera puedo ver (aguja en una pila de heno). Entonces, ahora implemento la lógica primero y cuando descubro qué datos necesito, los agrego como un parámetro o lo agrego a un objeto de parámetro. Conseguir que el resto del código se ajuste a esta nueva interfaz generalmente recae en una clase de mediador de algún tipo.

Sin embargo, como dije, debe tener mucho en cuenta al escribir capas comerciales, incluido el rendimiento. El enfoque anterior ha sido útil últimamente porque aún no tengo derechos para el control de versiones o el esquema de la base de datos. Estoy trabajando en una sala oscura con solo mi comprensión de los requisitos hasta ahora.

Escribir con pruebas en mente Utilizar la inyección de dependencia puede ser útil para diseñar una buena arquitectura por adelantado. Intente pensar cómo probaría su código sin acceder a una base de datos u otro servicio. Esto también se presta a clases pequeñas y reutilizables que pueden ejecutarse en contextos múltiples.

Conclusión Mi conclusión es que realmente no existe una capa empresarial perfecta. Incluso en la misma aplicación, puede haber ocasiones en que un enfoque solo funciona el 90% del tiempo. Lo mejor que podemos hacer es intentar escribir lo más simple que funcione. Durante mucho tiempo evité los DTO y envolví ADO.NET DataRows con objetos para que las actualizaciones se registraran inmediatamente en el DataTable subyacente. Este fue un ENORME error porque no pude copiar los objetos y las restricciones causadas por las excepciones que se lanzaron en tiempos extraños. Solo lo hice para evitar establecer valores de parámetros explícitamente.

Yo tampoco. No creamos una capa empresarial en nuestras aplicaciones. En cambio usamos MVC-ARS . La lógica de negocios está integrada en la máquina de estados (S) y la acción (A).