Pregunta

La aplicación web principal de mi empresa pide a gritos un conjunto ingenioso de bibliotecas para que de alguna manera sea mantenible y escalable, y uno de mis colegas sugirió CSLA.Entonces compré el libro pero como:

Los programadores ya no leen libros.

Quería evaluar la opinión de la comunidad SOFlow al respecto.

Asi que aqui están mis preguntas:

  1. ¿Cuántas personas utilizan CSLA?
  2. ¿Cuáles son los pros y los contras?
  3. ¿CSLA realmente no encaja con TDD?
  4. ¿Cuáles son mis alternativas?
  5. Si has dejado de usarlo o has decidido no hacerlo ¿por qué?
¿Fue útil?

Solución

Antes de responder específicamente a su pregunta, me gustaría dejar algunas ideas.¿CSLA es adecuado para su proyecto?Eso depende.Personalmente, consideraría CSLA para aplicaciones de escritorio que no valoran las pruebas unitarias como una alta prioridad.CSLA es excelente si desea escalar fácilmente a una aplicación de n niveles.CSLA tiende a recibir algunas críticas porque no permite pruebas unitarias puras.Esto es cierto, sin embargo, como todo en la tecnología, creo que hay No hay un camino verdadero.Es posible que las pruebas unitarias no sean algo que esté realizando para un proyecto específico.Lo que funciona para un equipo y un proyecto puede no funcionar para otro equipo u otro proyecto.

También existen muchas ideas erróneas con respecto a CSLA.No es un ORM.no es un competidor de NHibernate (de hecho, usar CLSA Business Objects y NHibernate como acceso a datos encajan muy bien).Formaliza el concepto de Objeto móvil.

1.¿Cuántas personas utilizan CSLA?
Basado en el Foros de CSLA, Yo diría que existen bastantes proyectos basados ​​​​en CSLA.Honestamente, no tengo idea de cuántas personas lo están usando.Lo he usado en el pasado en dos proyectos.

2.¿Cuáles son los pros y los contras?
Si bien es difícil resumirlo en una lista breve, aquí presentamos algunos de los pros y los contras que me vienen a la mente.
Ventajas:

  • Es fácil poner a los nuevos desarrolladores al día.El libro CSLA y la aplicación de muestra son excelentes recursos para ponerse al día.
  • El marco de Validación es verdaderamente de clase mundial y ha sido "tomado prestado" para muchos otros proyectos y tecnologías que no pertenecen a CSLA.
  • Deshacer de n niveles dentro de sus objetos comerciales
  • Cambio de línea de configuración para escalabilidad de n niveles (Nota:ni siquiera es necesario una recompilación)
  • Las tecnologías clave se abstraen del código "real".Cuando se introdujo WCF, tuvo un impacto mínimo en el código CSLA.
  • Es posible compartir sus objetos comerciales entre Windows y proyectos web.
  • CSLA promueve la normalización de comportamiento en lugar de la normalización de datos (dejando la base de datos para la normalización de datos).

Contras:

  • Dificultad en las pruebas unitarias.
  • Falta de separación de intereses (generalmente sus objetos comerciales tienen un código de acceso a datos dentro de ellos).
  • Mientras CSLA promueve la normalización de comportamiento, en lugar de la normalización de datos, y esto puede dar como resultado objetos comerciales con nombres similares, pero con propósitos diferentes.Esto puede causar cierta confusión y la sensación de que no estás reutilizando los objetos adecuadamente.Dicho esto, una vez que se da el salto fisiológico, tiene más sentido: parece inapropiado estructurar los objetos a la "antigua".
  • No está "de moda" crear aplicaciones de esta manera.Puede que le resulte difícil conseguir desarrolladores apasionados por la tecnología.

3.Después de leer esto, ¿CSLA realmente no encaja con TDD?
No he encontrado una forma eficaz de hacer TDD con CSLA.Dicho esto, estoy seguro de que hay muchas personas más inteligentes que yo que pueden haber intentado esto con mayor éxito.

4.¿Cuáles son mis alternativas?
El diseño basado en dominios está recibiendo un gran impulso en este momento (y con razón: es fantástico para algunas aplicaciones).También hay una serie de patrones interesantes que se desarrollan a partir de la introducción de LINQ (y LINQ to SQL, Entity Framework, etc.).libro de cazadores PoEAA, detalla muchos patrones que pueden ser adecuados para su aplicación.Tenga en cuenta que algunos patrones compiten (es decir,Active Record and Repository) y, por lo tanto, están destinados a usarse en escenarios específicos.Si bien CSLA no coincide exactamente con ninguno de los patrones descritos en ese libro, se parece más a Active Record (aunque creo que es miope afirmar una coincidencia exacta para este patrón).

5.Si has dejado de usarlo o has decidido no hacerlo ¿por qué?
No recomendé completamente CSLA para mi último proyecto porque creo que el alcance de la aplicación es demasiado grande para los beneficios que proporciona CSLA.
me gustaría no Utilice CSLA en un proyecto web.Siento que existen otras tecnologías más adecuadas para crear aplicaciones en ese entorno.

En resumen, si bien CSLA es cualquier cosa menos una bala de plata, es apropiado para algunos escenarios.

¡Espero que esto ayude!

Otros consejos

Después de leer todas las respuestas, me di cuenta de que bastantes personas tienen algunas ideas erróneas sobre CSLA.

Primero, CSLA no es un ORM.¿Cómo puedo decir eso tan definitivamente?Porque el propio Rockford Lhotka lo ha dicho muchas veces en entrevistas en el Rocas .NET y Hanselminutos podcasts.Buscar cualquier episodio donde Rocky fue entrevistado y lo declarará en términos muy claros.Creo que este es el hecho más importante que la gente debe comprender, porque casi todos los conceptos erróneos sobre CSLA surgen de creer que es un ORM o de intentar utilizarlo como tal.

Como aludió Brad Leach en su respuesta, los objetos CSLA modelan el comportamiento, aunque puede ser más exacto decir que modelan el comportamiento de los datos, ya que los datos son parte integral de ellos.CSLA no es un ORM porque es completamente independiente de cómo se comunica con su almacén de datos.Tú debería use algún tipo de capa de acceso a datos con CSLA, tal vez incluso un ORM.(Sí.Ahora uso Entity Framework, que funciona muy bien).

Ahora, pasemos a las pruebas unitarias.Nunca he tenido ninguna dificultad para probar mis objetos CSLA, porque no coloco mi código de acceso a datos directamente en mis objetos comerciales.En lugar de eso, utilizo alguna variación del patrón del repositorio. CSLA consume el repositorio, no al revés. Al intercambiar un repositorio falso para mis pruebas unitarias y usar el portal de datos local, ¡AUGE! es sencillo.(Una vez que Entity Framework permita el uso de POCO, esto será aún más limpio).

Todo esto surge al darnos cuenta de que CSLA no es un ORM.Puede consumir un ORM, pero en sí mismo no lo es.

Salud.

ACTUALIZAR

Pensé en hacer algunos comentarios más.

Algunas personas han dicho que CSLA es detallado en comparación con cosas como LINQ to SQL, etc.Pero aquí estamos comparando manzanas con naranjas.LINQ to SQL es un ORM.Ofrece algunas cosas que CSLA no ofrece, y CSLA ofrece algunas cosas que L2S no ofrece, como validación integrada y nortePersistencia de niveles a través de los distintos portales de datos remotos.De hecho, diría lo último, norte-Persistencia de nivel, los supera a todos para mí.Si quiero usar Entity Framework o LINQ to SQL en la red, tengo que poner algo como WCF de por medio, y eso multiplica enormemente el trabajo y la complejidad, hasta el punto que creo que es mucho más detallado que CSLA.(Ahora soy fanático de WCF, REST y SOA, pero lo uso donde realmente lo necesita, como cuando desea exponer un servicio a terceros.Para la mayoría de las aplicaciones de línea de negocios, no es realmente necesario y CSLA es una mejor opción). De hecho, con la última versión de CSLA, Rocky proporciona una WCFDataPortal, que he usado.Funciona muy bien.

Soy un fan de SÓLIDO, TDD y otros principios modernos de desarrollo de software, y utilícelos siempre que sea práctico.Pero creo que los beneficios de CSLA superan algunas de las objeciones de esas ortodoxias y, en cualquier caso, he logrado que CSLA funcione bastante bien (y fácilmente) con TDD, así que eso no es un problema.

Sí, lo usé (um, nosotros) ampliamente para modelar nuestra lógica de proceso de negocios que consistía principalmente en formularios vinculados a datos en una aplicación de formularios de Windows.La aplicación era un sistema comercial.CSLA está diseñado para estar en esa capa justo debajo de la interfaz de usuario.

Si piensa en su aplicación de línea de negocio compleja estándar, puede tener un formulario con muchos campos, muchas reglas para esos campos (incluidas reglas de validación entre campos), puede invocar un diálogo modal para editar algún objeto secundario, puede desea poder cancelar dichos diálogos y volver a un estado anterior.CSLA apoya esto.

Sus desventajas son que tiene una pequeña curva de aprendizaje.

La clave para recordar es utilizar CSLA para modelar cómo usuario interactúa con formularios en alguna aplicación.La forma más eficiente para mí fue diseñar la interfaz de usuario y comprender sus flujos, comportamiento y reglas de validación antes de construir los objetos CSLA.No haga que sus objetos CSLA impulsen el diseño de la interfaz de usuario.

También nos resultó muy útil poder utilizar el lado del servidor de objetos comerciales de CSLA para validar los objetos enviados desde los clientes.

También teníamos mecanismos integrados para realizar la validación de forma asincrónica contra el servicio web (es decir,comprobar el rango de límite de crédito de una contraparte frente a un maestro).

CSLA impone una fuerte separación entre su interfaz de usuario, BusinessLogic y Persistance y escribimos una gran cantidad de pruebas unitarias para ellos.Puede que no sea estrictamente TDD porque lo estás manejando desde el diseño de la interfaz de usuario, eso no significa que no sea comprobable.

La única alternativa real es crear su propio modelo/objetos de negocio, pero muy pronto terminará implementando características que CSLA ofrece listas para usar (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState, etc.)

Utilicé CSLA para un proyecto y funcionó muy bien y hizo las cosas mucho más simples y ordenadas.

En lugar de que su equipo escriba objetos comerciales con su propio estilo personal diferente, sabemos que tenemos un estándar común con el que trabajar.

//andy

Tuve experiencia con eso hace varios años.Es una arquitectura brillante, pero muy compleja, difícil de entender o cambiar, y está resolviendo un problema que la mayoría de nosotros que desarrollamos aplicaciones basadas en web no necesariamente tenemos.Fue desarrollado más para aplicaciones basadas en Windows y para manejar deshacer en varios niveles, con un gran énfasis en la lógica transaccional.Probablemente escuche a la gente decir que dado que las aplicaciones web son solicitud-respuesta a nivel de página, esto es inapropiado, pero con las aplicaciones web de estilo AJAX tal vez este argumento no sea tan válido.

Tiene un modelo de objetos muy profundo y puede llevar un tiempo comprenderlo realmente.Por supuesto, muchas cosas pueden cambiar en unos pocos años.Me interesaría escuchar otras opiniones recientes.

A fin de cuentas, no sería mi primera elección de arquitectura.

En defensa de la CSLA, aunque estoy de acuerdo con muchos de los comentarios que se han hecho, particularmente el de pruebas unitarias...

Mi empresa lo utilizó ampliamente para una aplicación de entrada de datos de Windows Forms, con un alto grado de éxito.

  • Proporcionó una funcionalidad lista para usar que no teníamos el tiempo ni la experiencia para escribir nosotros mismos.
  • Estandarizó todos nuestros objetos comerciales, facilitando el mantenimiento y reduciendo la curva de aprendizaje para nuestros nuevos desarrolladores.

En general, diría que cualquier problema que haya causado fue más que superado por los beneficios.

ACTUALIZAR:Además de esto, todavía lo usamos para nuestra aplicación Windows Forms, pero los experimentos con su uso para otras aplicaciones, como sitios web, han demostrado que quizás sea demasiado engorroso cuando no se necesita mucha de su funcionalidad y ahora estamos investigando un peso más ligero. opciones para estos escenarios.

Me uní a un equipo donde CSLA es obligatorio.No utilizamos el portal de datos remotos, que es la única razón por la que puedo aceptar el uso de este marco.Nunca creí la idea de CSLA, así que tal vez por eso no tengo más que problemas, lo siento.

Un par de problemas:

No necesito un obstáculo entre mi código y el marco .NET, que es lo que sentí este marco para mí.Tenía una opción limitada de objetos de lista, mientras que solo tenía que ignorar los objetos de lista enriquecidos en el marco .NET.

Es totalmente ridículo que tuviéramos estas listas de solo lectura y luego listas de no solo lectura.Entonces, si tuviera que agregar un elemento a la lista, tendría que recrear la lista completa... ¿Hablas en serio?

Luego csla quiere administrar el estado de mi objeto, lo cual está bien, pero no hay nada realmente expuesto.A veces quiero cambiar el estado de un objeto manualmente en lugar de recuperarlo, lo que parece ser lo que csla quiere que haga.Básicamente termino creando muchas propiedades para exponer opciones a las que csla no pensó que debería tener acceso directo.

¿Por qué no puedo simplemente crear una instancia de un objeto?Terminamos creando métodos estáticos que crean una instancia de un objeto y lo devuelven... ¿estás bromeando?

Verifique el código fuente del marco y me parece demasiado pesado en el código de reflexión.

Razones para utilizar csla:

  • el marco .net simple es demasiado poderoso para usted.
  • Si sus desarrolladores no tienen experiencia y no pueden comprender el concepto de patrones, entonces csla prácticamente tendrá a todos en la misma página.

    1. No necesito un obstáculo entre mi código y el marco .NET... Estoy atrapado con estos objetos de lista.

Comenzamos a usar CSLA porque pensamos que ayudaría con nuestra capa de modelo.Fue una especie de exageración y principalmente todo lo que usamos ahora es la clase SmartDate, solo porque ya estamos vinculados a la biblioteca.

Pensamos que la interfaz de validación realmente nos ayudaría a hacer cumplir las reglas comerciales, pero no funcionó bien con WCF y la serialización (todavía estamos estancados en la versión 2.0.3.0, por lo que es posible que las cosas hayan cambiado).

No quitar CSLA de la lista, pero antes de usarlo, investigue los beneficios y asegúrese de que realmente se apliquen.¿Su equipo podrá implementarlo de manera correcta y consistente?¿Se necesita baile de portal y remoto?

Creo que más allá de toda la reflexión teórica, se trata de un código limpio, mantenible, ampliable y comprobable que siga patrones básicos probados.

Conté líneas de código necesarias en un dominio específico de un proyecto convertido de CSLA.Entre todos los diferentes objetos CSLA (combinaciones de solo lectura+editable+raíz+lista) y sus procesos almacenados, se necesitaron alrededor de 1700 líneas, frente a una implementación de Linq2SQL + Repository que tomó 180 líneas.La versión Linq2SQL consistía principalmente en clases generadas que su equipo no necesita consumir libros para comprender.Y sí, usé CodeSmith para generar las partes de CSLA, pero ahora creo en el código DRY con bits de responsabilidad única, y la implementación de CSLA ahora me parece el héroe de ayer.

Como alternativa, me gustaría sugerir buscar en Linq2Sql/Entity Framework/NHibernate combinado con los patrones Repository y UnitOfWork.Mira esto http://www.codeplex.com/backgroundmotion

¡Salud!

Nuestra empresa practicó CSLA en algunos de sus proyectos y algunos de los proyectos heredados siguen siendo CSLA.Otros proyectos se alejaron de él porque CSLA violó una regla de programación orientada a objetos simple y llanamente:Principio de Responsabilidad Única.

Los objetos CSLA son autosostenibles, p.recuperan sus propios datos, gestionan su propio comportamiento, se salvan.Desafortunadamente, esto significa que su objeto CSLA promedio tiene al menos tres responsabilidades: representar el modelo de dominio, contener reglas comerciales y contener la definición de acceso a datos (no el DAL o la implementación de acceso a datos, como indiqué/insinué anteriormente), todo al mismo tiempo.

Usamos CSLA ampliamente.Hay varios beneficios;En primer lugar, creo que todos los desarrolladores de líneas de negocio deberían leer el libro de Rocky Lhotka sobre programación de Business Objects.Personalmente, descubrí que está entre mis 3 mejores libros de programación.CSLA es un marco basado en este libro y su uso le brinda a su proyecto acceso a funcionalidades de muy alto nivel, como deshacer de nivel n, reglas de validación y arquitectura de escalabilidad, al mismo tiempo que le proporciona los detalles.Observe que dije "proporcionar" y no "ocultar".Descubrí que la mejor parte de CSLA es que te permite comprender cómo se implementan todas estas cosas hasta el código fuente sin tener que reproducirlas tú mismo.Puede optar por utilizar tantas o pocas funciones como necesite, pero descubrí que mantenerse fiel a los patrones de diseño del marco realmente lo mantiene fuera de problemas.--Byron

Hemos estado usando CSLA durante más de cinco años y creemos que funciona muy bien para crear aplicaciones comerciales.Junto con la generación de código, puede crear objetos comerciales en un período de tiempo relativamente corto y centrar su esfuerzo en el carne de la aplicación.

He estado usando CSLA desde vb5, cuando era más una colección de patrones que un marco.Con la introducción de .NET, CSLA se convirtió en un marco completo, que conllevaba una considerable curva de aprendizaje.Sin embargo, la CSLA aborda muchas cosas que todos los desarrolladores de negocios tienden a escribir ellos mismos en algún momento (dependiendo del alcance del proyecto):lógica de validación, lógica de autenticación, funcionalidad de deshacer, lógica sucia, etc.Todas estas cosas se obtienen de forma gratuita y listas para usar en un marco agradable.

Como han dicho otros, al ser un marco, obliga a los desarrolladores a escribir la lógica empresarial de manera similar.También lo obliga a proporcionar un nivel de abstracción para su lógica de negocios, de modo que no utilizar un marco de interfaz de usuario como MVC, MVP, MVVM no sea tan importante.

De hecho, yo diría que la razón por la que muchos de estos patrones de UI están tan publicitados hoy (en el mundo de Microsoft) es que la gente ha estado haciendo cosas increíblemente mal durante tanto tiempo (es decir, usar DataGrids en su UI, esparcir su lógica de negocios en todas partes.tisk tisk).Diseñe su nivel medio (lógica de negocios) correctamente desde el principio, puede reutilizar su nivel medio en CUALQUIER interfaz de usuario.Win Form, ASP.NET/MVC, Servicio WCF, WPF, Silverlight**, Servicio de Windows, ....

Pero aparte de esto, la gran recompensa para mí ha sido su capacidad incorporada de escalar.CSLA utiliza un patrón de proxy que se puede configurar a través de su archivo de configuración.Esto permite que sus objetos comerciales realicen llamadas remotas de un servidor a otro, sin tener que escribir ni una pizca de código.¿Agregar más usuarios a su sistema?No hay problema, implemente sus objetos comerciales CSLA en un nuevo servidor de aplicaciones, realice un cambio en la entrada del archivo de configuración y ¡¡BAM!!Se satisfacen las necesidades de escalabilidad instantánea.

Compare esto con el uso de DTO, almacenar su lógica de negocios en el cliente (cualquiera que sea el cliente) y tener que escribir cada uno de sus propios métodos CRUD como métodos de servicio.¡¡¡Ay!!!No digo que este sea un mal enfoque, pero no me gustaría hacerlo.No cuando existe un marco para hacerlo esencialmente por mí.

Voy a reiterar lo que otras personas han dicho: CSLA NO es un ORM.CSLA le obliga a suministrar datos a sus objetos comerciales.No les importa de dónde obtienes tus datos.Puede utilizar un ORM para suministrar datos a sus objetos comerciales.También puede utilizar ADO.NET sin formato, otros servicios (RESTFUl, SOAP), hojas de cálculo de Excel, puedo continuar aquí.

En cuanto a su soporte para TDD, tampoco he intentado utilizar ese enfoque con CSLA.He adoptado el enfoque en el que modelo mi nivel medio (como objetos de negocio) utilizando diagramas de clases y secuencias, permitiendo en la mayoría de los casos que dicte el diseño de casos de uso, pantalla y/o procesos.Quizás un poco de la vieja escuela, pero UML siempre me ha sido de gran utilidad en mis esfuerzos de diseño y desarrollo.He diseñado y desarrollado con éxito aplicaciones muy grandes y escalables que todavía se utilizan en la actualidad.Y hasta que WCF RIA madure, seguiré usando CSLA.

** con algunas soluciones

Soy nuevo en CSLA pero entiendo los conceptos y ya entiendo que no es una herramienta ORM, así que dejen de tocar ese maldito tambor.Hay características de CSLA que me gustan, pero usarlas se siente como si hubiera un mago detrás de la cortina.Supongo que si no te importa no saber cómo funciona, puedes usar los objetos y funcionan bien.

Hay una gran curva de aprendizaje para principiantes y creo que sería muy beneficioso tener entre 5 y 15 minutos.Vídeos como los que tiene Microsoft para aprender los fundamentos.¿O qué tal publicar un libro complementario con el código en lugar de publicar el código y tardar meses en publicar el libro?Sólo digo Sr. Lohtka...Empezamos a construir nuestras cosas antes del libro y tuve problemas todo el tiempo.Pero como dije, soy nuevo en esto.

Usamos CSLA.Hicimos que nuestros objetos se ajustaran a su molde y luego utilizamos el 10% de lo que ofrecía el marco.¿Deshacer a nivel de objeto?No lo usé.¿Flexibilidad de nivel N?No lo usé.Terminamos escribiendo suficiente código de reglas comerciales que pensé que lo único que obteníamos de CSLA era complejidad.Algunos desarrolladores veteranos que conocen la estructura la usaron como martillo porque tenían un clavo que necesitaba golpear.CSLA estaba en su haber y supongo que muchos defensores del marco también ven las cosas desde esa perspectiva.

Supongo que nuestros desarrolladores experimentados están contentos porque todo tiene sentido para ellos.Supongo que si su organización no tiene programadores novatos y se aburren escribiendo objetos POCO simples y eficientes con patrones bien formados, entonces hágalo.Utilice CSLA.

Estoy usando CSLA como marco de objetos comerciales para un proyecto de tamaño mediano.El marco ha recorrido un largo camino desde los días de VB6 y ofrece una extraordinaria cantidad de flexibilidad y funcionalidad "lista para usar".Los objetos inteligentes móviles de CSLA facilitan mucho el desarrollo de la interfaz de usuario.Sin embargo, estoy de acuerdo con otros en que no es la herramienta adecuada para cada situación.Definitivamente hay algunos gastos generales involucrados, pero también mucha potencia.Personalmente, tengo muchas ganas de utilizar CSLA Light con Silverlight.

Ventajas:

  • Agnóstico de la tecnología de datos1
  • ¡Gran base de instalación y es GRATIS!
  • Marco estable y lógico
  • El código de acceso a datos puede estar en sus objetos o en un ensamblaje separado
  • Validación y autorización de bienes y objetos

Contras

  • El código puede ser mucho para mantener.2
  • Probablemente necesite un generador de código para usarlo de manera efectiva
  • Curva de aprendizaje.La estructura de los objetos CSLA es fácil de comprender, pero las advertencias pueden generar dolores de cabeza.


No estoy seguro acerca del diseño basado en pruebas.No realizo pruebas unitarias ni diseño impulsado por pruebas (qué vergüenza), por lo que no sé si las pruebas unitarias son diferentes de TDD, pero sé que la versión más reciente del marco viene con pruebas unitarias.


1 Lo bueno es que las tecnologías de acceso a datos nunca permanecen iguales por mucho tiempo.
2 Esto ha mejorado con las versiones recientes del marco.

Mucha gente recomienda utilizar Code Generation con CSLA.Recomiendo consultar nuestro conjunto de plantillas compatibles, ya que aumentarán enormemente su retorno de la inversión.

Gracias -Blake Niemyjski (autor de la Plantillas CSLA de CodeSmith)

Lo usé para un proyecto hace un par de años.Pero cuando el proyecto estuvo terminado, no pude decirle a nadie lo que CSLA hizo por mí.Claro, heredé de sus clases.Pero pude eliminar esa herencia de casi todas las clases sin ninguna reestructuración.No teníamos ningún uso para las cosas de N-Tier.El deshacer de nivel n fue tan lento que no pudimos usarlo.Supongo que al final solo nos ayudó a modelar nuestras clases.

Dicho esto, otros equipos han comenzado a usarlo (después de un horrible intento por parte de un equipo de crear su propio marco).Así que tiene que haber algo que valga la pena ahí, ¡porque todos son más inteligentes que yo!

Soy un chico de PHP.Cuando comenzamos a crear aplicaciones de escala comparativamente grande con PHP, comencé a investigar sobre muchos marcos de aplicaciones y ORM esencialmente en el mundo PHP, luego en Java y .NET.La razón por la que también miré los marcos Java y .NET fue no usar ciegamente ningún marco PHP, sino primero tratar de comprender qué está sucediendo realmente y qué tipo de arquitecturas de nivel empresarial existen.

Debido a que no he usado CSLA en una aplicación del mundo real, no puedo comentar sobre sus pros y contras, pero lo que puedo decir es que Lhotka es uno de los raros pensadores (no digo solo un experto) en el campo de la arquitectura de software.Aunque el nombre Domain Driven Design fue acuñado por Eric Evans (por cierto, su libro también es excelente y humildemente aconsejo leerlo), Lhotka estuvo aplicando el diseño impulsado por dominios durante años.Dicho esto, independientemente de lo que piense sobre su marco, benefíciese de sus profundas ideas en el campo.

Puede encontrar sus charlas en dotnetrocks.com/archives.aspx y videos en dnrtv.com/archives.aspx (busque Lhotka).

@Byron ¿Cuáles son los otros dos libros que te gustó?

John,

Tenemos equipos trabajando en CSLA de 2 a 3.5 y hemos encontrado que es una excelente manera de proporcionar un marco consistente para que todos los desarrolladores "lo hagan de la misma manera".Es fantástico que se genere la mayor parte del código de bajo valor y sepamos que cuando ejecutamos pruebas unitarias funcionan de inmediato para todas las cosas CRUD.Descubrimos que nuestro TDD realmente viene con la refactorización que hacemos para diseñar, y CSLA no nos impide hacer nada de eso.

cris

La última vez que intenté usar CSLA fue en los días de la edad de piedra de VB6.En retrospectiva, habría sido más eficaz si hubiera utilizado la generación de código.Si no tiene herramientas efectivas de generación de código y una estrategia para adaptarlas a su flujo de trabajo, debe evitar marcos como CSLA; de lo contrario, las funciones que obtiene de CSLA no compensarán la cantidad de tiempo que dedica a escribir n líneas. de código por tabla, n líneas de código por columna, etc.

He usado CSLA.NET en algunos proyectos hasta ahora, tuvo más éxito en una aplicación de Windows Forms que tiene ricas compatibilidades de enlace de datos (que las aplicaciones asp.net no tienen).

Su principal problema es el soporte TDD, como la gente ha estado señalando, esto se debe al comportamiento similar a una caja negra para las funciones Dataportal_XYZ y su incapacidad para permitirnos burlarnos de los objetos de datos.Se han realizado esfuerzos para solucionar este problema con este siendo el mejor enfoque

Quería usarlo, pero mi entonces desarrollador principal tenía la idea de que había demasiada "magia" involucrada...

CSLA es el mejor marco de aplicaciones que existe.Rocky LHotka es un tipo muy pero muy inteligente.Está escribiendo la historia del desarrollo de software como Martin Fowler, David S Platt, pero mis escritores favoritos son Rod Stephens, Mathew McDonalds, Jeff Levinson, Thearon Willis y Louis Davidson, alias Dr. SQL.:-) Pros:Se aplican todos los patrones de diseño.Contras:Difícil de aprender y pocas muestras.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top