csla

¿Qué es CSLA Framework y su uso?



(6)

¿Qué es CSLA Framework y su uso?

CSLA es un marco de objetos de negocios que le permite crear fácilmente objetos de negocios sobre una capa de datos. Le permite diseñar su aplicación con principios sólidos orientados a objetos y una buena separación de inquietudes.

Le recomiendo que lea el libro de CSLA de Rocky Lhotka llamado Expert C # 2008 Business Objects. Eso no solo le enseñará sobre el marco, sino que también enseñará buenos principios de arquitectura de software.

Puedes tomar el libro aquí en Amazon

CSLA se describe en detalle here . El nuevo libro es un gran punto de partida. Como un gran complemento al libro, recomendaría revisar nuestras plantillas CSLA 3.8 . Rocky recomienda usar un generador de código, y tenemos el conjunto líder de plantillas, que lo pondrá en funcionamiento en muy poco tiempo.

Gracias -Blake Niemyjski (Autor de las plantillas de CodeSmith CSLA )

CSLA: Arquitectura lógica escalable basada en componentes

Un párrafo en pocas palabras que me describió a CSLA del sitio web fue este:

CSLA .NET le permite crear una capa empresarial orientada a objetos que abstrae y encapsula su lógica y datos comerciales. El marco garantiza que sus objetos de negocio funcionen sin problemas con todas las tecnologías de interfaz .NET, incluidas WinRT XAML, WPF, ASP.NET MVC, ASP.NET Web Forms, WCF, servicios asmx, Windows Phone 7, Silverlight, Windows Workflow y Windows Forms.

Por qué podrías usarlo:

Gestión de reglas de negocio. Una vez que aprenda el sistema de reglas de negocios, proporcionará una manera de imponer la lógica de negocios en un paquete ordenado. Si tiene un objeto con objetos secundarios que necesitan reportar la Validación al nivel más primario, hay una manera de manejar eso. (vea http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx para obtener más información sobre el sistema de reglas)

¿Tiene objetos de negocio que necesita para soportar deshacer N-level? Un BusinessBase de CSLA tiene un sistema de administración de propiedades al horno (como propiedades de dependencia) para funcionalidades como Deshacer de nivel N (en realidad está completamente implementado). (Esto también se relaciona con la administración de reglas de negocios. Puede activar la validación cuando una propiedad primaria cambia, o puede cambiar una propiedad basándose en el valor de otra propiedad.)

Gestión del portal de datos. Este fue un concepto interesante. Si necesito ejecutar operaciones de datos localmente, CSLA está configurado para esto de forma inmediata. También puedo instalar un servicio WCF que hace referencia a mis bibliotecas de objetos de negocios y usar algunas líneas de configuración para hacer un punto final de WCF para administrar las operaciones de datos. El servicio WCF es parte del marco CSLA. Fue genial ver esto en acción. ¿Otros escenarios? ¡Por supuesto! Su biblioteca de objetos de negocio no necesita cambiar, la clase DataPortal determina si necesita ejecutarse de forma remota o local, de acuerdo con su configuración.

CSLA le obliga a usar algunos mecanismos que pueden no sentirse naturales al principio. Creo que eso es cierto de cualquier patrón que decidas implementar. Sin embargo, cuando se trata de los desafíos de la implementación de la Arquitectura Orientada a Servicios, CSLA ofrece mucho. Sí, vas a tener un desarrollador de nivel de arquitecto que crea algunas de tus bibliotecas. Sin embargo, si está creando una aplicación de clase empresarial, ¿no debería estar haciendo eso ya?

CSLA, cuando está correctamente diseñado, es comprobable. Usamos el patrón de repositorio para reemplazar el dal real con una capa simulada y probamos por especificación (usando NUnit / SpecFlow) y de forma unitaria cuando sea apropiado.

En cuanto al apoyo, incluido el propio Rocky, hay una comunidad de colaboradores que garantizan que cosas como CSLA.Net para Xamarin se conviertan en una realidad. Hay consultorías que conocen CSLA y lo usan de manera regular según el alcance del trabajo (y no, no solo la consultoría para la que trabajo).

A fin de cuentas, es posible que CSLA no sea para ti. Como otros lo han indicado, lea el sitio y los libros (especialmente Business C # 2008 de Business Objects). Haga preguntas, ya que la comunidad de CSLA tiende a dar consejos de calidad.

En respuesta a @radarbob https://.com/a/10922373/261363 , espero no lamentar esto y comenzar una guerra de llamas.

Nuestro equipo ha estado desarrollando un par de aplicaciones LOB con CSLA. De mi experiencia en escribir aplicaciones de campo verde con CSLA y mantener el código existente aquí están mis respuestas a sus puntos.

  1. El BO no debe hacer su propia persistencia de datos, tendrá una Fábrica que manejará toda la persistencia de los datos, por ejemplo, utilizando un ORM para mapear los Modelos que luego se guardarán.

  2. Lamento escuchar eso, me aseguro de estudiar la documentación del marco y escribir al menos una aplicación de juguete antes de ingresar a una base de datos de códigos existente. Además puedes incluso descargar y navegar el código CSLA.

  3. Usted tiene BO -> Portal -> Fábricas que no deberían ser muy complicadas. Los ejemplos existentes de CSLA explican lo que está sucediendo en cada nivel.

  4. CLSA nunca debe confundirse con un ORM

  5. Como es debido, los objetos comerciales rara vez se asignan a una tabla y, por lo tanto, requieren un poco de trabajo al guardar. En el caso de que estén asignados a una tabla, use algo como AutoMapper para asignar su BO a su POCO en 1 línea.

  6. Mire en los Comandos de CSLA, tampoco hay nada que le impida mantener su BO tan pequeño o grande como quiera, siempre y cuando tenga en cuenta que no son lo mismo que los POCO que persiste.

En un proyecto en el que trabajamos, pudimos probar fácilmente BO para garantizar que la lógica de negocios fuera correcta. Debido a la buena separación de las preocupaciones, probamos nuestras Fábricas de forma aislada para asegurarnos de que los objetos comerciales se conservarán en consecuencia.

En un momento pude persistir fácilmente parte de mis BO''s en MongoDB, por lo que la aplicación se ejecutaba en una base de datos híbrida MSSQL y MongoDB sin tener que cambiar una línea de código en mis objetos comerciales, todo lo que tenía que hacer era actualizar el Fábricas para utilizar Mongo en lugar del ORM actual.

Espero que esto aborde todos sus puntos de una manera justa,

Saludos

Mis opiniones de mi experiencia con una base de código LOC de 1.7M:

  1. CSLA está destinado a un entorno de base de datos / aplicación distribuida. Es por esto que el objeto de negocio básico es y lo hace todo, por ejemplo, su propia persistencia de datos. Un objeto (y todo lo que se asocie de forma remota con su estado) está destinado a ser serializado, enviado a una aplicación y / o servidor de datos y trabajo diferente.
  2. Si lo anterior no es un problema que deba resolver, CSLA es una exageración, un gran momento. Nuestro equipo de desarrollo lamenta haberse comprometido con CSLA.
  3. Hacer malabares con todas las bolas de CSLA en una compleja interfaz de usuario con vientos es difícil. Tenemos pantallas de múltiples pestañas (que a su vez pueden abrir subpantallas) que, a menos que siga el flujo de entrada de datos "de izquierda a derecha, de arriba a abajo", y haga clic en guardar a menudo, termina poniendo y / o recuperando datos incompletos a / desde la base de datos; o eliminando todos los datos que acaba de ingresar. Sí, nuestros codificadores originales tienen la culpa, pero también CSLA ... Parece que hay muchas partes móviles para habilitar, controlar y coordinar las funciones de CSLA. Es como tener que lidiar con todos los diales e interruptores de un avión de combate cuando todo lo que necesitas es algo más como un Cessna 152.
  4. Escribirá muchos códigos personalizados para habilitar las características de CSLA. Por ejemplo, CSLA nunca se confundirá con herramientas de mapeo relacional de objetos (ORM) como Hibernate y Entity Framework. Nuestros métodos SAVE () no son triviales, por lo que son los triviales.
  5. Fomentar el uso de generadores de código agrava los problemas. Usamos CodeSMith para generar clases a partir de tablas de datos. Así que terminamos con un código que tiene una correspondencia de tabla 1-1 a clase c #. Por lo tanto, debe escribir todo el código para manejar dataStore en sus objetos "reales".
  6. El almacén de datos / y la recuperación son muy ineficientes con CSLA. Debido al paradigma céntrico de BusinessObject-do-do-and-all-know-behemoth de Behemoth, los objetos terminan haciendo una captura e instanciación de datos de un objeto en un momento. Las colecciones de objetos compuestos agravan significativamente el problema. Un solo "obtener este objeto" siempre da como resultado una cascada de recopilaciones de datos independientes (una o más para cada objeto individual) para instanciar la totalidad de la herencia y las cadenas de relaciones compuestas. Se conoce como el "problema de consulta N + 1". Ah, y recuperar datos SIEMPRE crea un nuevo objeto, incluso si solo estamos actualizando uno existente. No es de extrañar que nuestras pantallas más complejas sean FUBAR.

Le permite diseñar su aplicación con principios sólidos orientados a objetos y una buena separación de inquietudes.

Si y no. En su mayoría no.

El BusinessObject maneja su propio almacenamiento de datos. Eso es anti separación de preocupaciones.

"Te permite ..." bueno, sí, también lo hace una pantalla de editor de texto en blanco, pero no te fuerza ni te alienta como lo hace MVC.NET framework, por ejemplo. En mi humilde opinión, CLSA ofrece un beneficio absolutamente nulo para garantizar que el código que desarrolle con él siga los "principios sólidos de OO". De hecho, los programadores con habilidades OO débiles (la mayoría, según mi experiencia) realmente se destacarán cuando utilicen CSLA. ¡Ay de la programadora de mantenimiento!

CSLA es el elemento principal del principio orientado a objetos sólidos a favor de la composición sobre la herencia. El código CLSA no se puede probar. Debido a que un marco heredado BusinessObject es, hace y necesita todo, todos a la vez, no es probable que pueda obtener mucha cobertura de prueba. No se puede obtener en las piezas porque todo está estrechamente acoplado. El marco no es susceptible de inyección de dependencia. Es una cortina de hierro de código.

Su código será difícil de depurar. Las pilas de llamadas se vuelven muy profundas y, a medida que te acercas al centro del sol, por así decirlo, todo se convierte en reflexión. Y simplemente te pierdes. período.

EDITAR 7 Mar 2016

¿Qué más información puedo agregar después de la publicación original? Dos cosas, tal vez:

En primer lugar, parece que CSLA tiene alguna promesa. Si supiéramos cómo hacer malabares con todas esas partes móviles juntos. Pero CSLA es tan enigmático que incluso las cosas que hemos hecho bien se corrompen con el tiempo. En mi humilde opinión, sin un CSLA de equipo muy fuerte, cualquier implementación está condenada. Sin una "fuente abierta" vibrante de referencias técnicas, capacitación y comunidad, es imposible. En casi una década, nuestro código CSLA, en mi análisis final, es solo una deuda técnica.

En segundo lugar, aquí hay un comentario reciente que hice a continuación:

Nuestra complejidad a menudo no parece encajar en la infraestructura de CSLA, por lo que escribimos fuera del marco. Esto y la mano de obra barata resulta en infracciones de SRP desenfrenadas y me hace golpear paredes de ladrillos al administrar la aplicación de reglas dinámicas, por ejemplo. Luego, la infraestructura principal / secundaria de CSLA propaga la validación de objetos compuestos, pero no siempre queremos relaciones c / p, por lo que escribimos más validación y código de tienda. Así que hoy nuestra implementación de CSLA es inconsistente y confusa. Refactorizar para mejorar CSLA tendrá profundos efectos dominó. Entonces después de esa inyección inicial, CSLA es esencialmente abandonado.

Fin Editar