.net - ¿Alguien tiene alguna experiencia real de CSLA?

frameworks (23)

Antes de responder específicamente a su pregunta, me gustaría dejar algunas reflexiones. ¿CSLA es adecuado para su proyecto? Depende. Personalmente, consideraría CSLA para aplicaciones basadas en escritorio que no valoran las pruebas unitarias como una alta prioridad. CSLA es ideal si desea escalar fácilmente a una aplicación de n niveles. CSLA tiende a tener problemas porque no permite pruebas de unidades puras. Esto es cierto, sin embargo, como todo lo relacionado con la tecnología, creo que no hay ningún camino verdadero . Las pruebas unitarias pueden no ser 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 hay muchos conceptos erróneos con respecto a CSLA. No es un ORM. no es un competidor de NHibernate (de hecho, el uso de CLSA Business Objects & NHibernate como acceso a datos encajan realmente bien). Formala el concepto de un objeto móvil .

1. ¿Cuántas personas están usando CSLA?
Con base en los foros de CSLA , diría que hay bastantes proyectos basados en CSLA. Honestamente, no tengo idea de cuántas personas realmente 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 corta, aquí están algunos de los pro / contra que se me ocurren.
Pros:

Es fácil obtener nuevos desarrolladores al día. El libro de CSLA y la aplicación de muestra son excelentes recursos para ponerse al día.
El marco de Validación es realmente de primera clase, y ha sido "prestado" para muchos otros proyectos y tecnologías ajenos a CSLA.
Deshacer n-level dentro de sus objetos comerciales
Cambio de línea de configuración para escalabilidad n-Tier (Nota: ni siquiera es necesaria 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 ventanas y proyectos web.
CSLA promueve la normalización del comportamiento en lugar de la normalización de los datos (dejando la base de datos para la normalización de datos).

Contras:

Dificultad en pruebas unitarias
La falta de separación de la preocupación (generalmente sus objetos comerciales tienen un código de acceso a datos dentro de ellos).
Como CSLA promueve la normalización del comportamiento , en lugar de la normalización de los datos , y esto puede dar como resultado objetos comerciales que se nombran de manera similar, pero tienen diferentes propósitos. Esto puede causar cierta confusión y la sensación de que no estás reutilizando los objetos de manera apropiada. Dicho esto, una vez que se toma el salto fisiológico, tiene más que un sentido: parece inapropiado estructurar objetos de la "vieja" manera.
No está "de moda" crear aplicaciones de esta manera. Puede que le cueste conseguir desarrolladores apasionados por la tecnología.

3. Después de leer esto ¿CSLA realmente no encaja con TDD?
No he encontrado una forma efectiva 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?
Domain-Driven-Design está obteniendo 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 a SQL, Entity Framework, etc.). Fowlers book PoEAA , detalla muchos patrones que pueden ser adecuados para su aplicación. Tenga en cuenta que algunos patrones compiten (es decir, Active Record y Repository) y, por lo tanto, deben utilizarse para escenarios específicos. Si bien CSLA no coincide exactamente con ninguno de los patrones descritos en ese libro, se asemeja mucho más al Registro activo (aunque creo que es miope reclamar una coincidencia exacta para este patrón).

5. ¿Si dejó de usarlo o decidió por qué?
No recomendé totalmente CSLA para mi último proyecto, porque creo que el alcance de la aplicación es demasiado grande para los beneficios que ofrece CSLA.
No usaría CSLA en un proyecto web. Siento que hay otras tecnologías más adecuadas para crear aplicaciones en ese entorno.

En resumen, aunque CSLA es todo menos una bala de plata , es apropiado para algunos escenarios.

¡Espero que esto ayude!

La principal aplicación web de mi empresa está pidiendo a gritos un conjunto ingenioso de bibliotecas para hacerlo de alguna forma mantenible y escalable, y uno de mis colegas ha sugerido CSLA. Así que compré el libro pero como:

los programadores ya no leen libros

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

Asi que aqui están mis preguntas:

¿Cómo pueden las personas usar CSLA?
¿Cuáles son los pros y los contras?
¿Realmente CSLA no encaja con TDD?
¿Cuáles son mis alternativas?
Si ha dejado de usarlo o ha decidido por qué?

Empezamos a usar CSLA porque pensamos que ayudaría con nuestra capa de modelo. Fue un poco exagerado y, en general, todo lo que usamos ahora es la clase SmartDate, simplemente 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 atascados en la versión 2.0.3.0, por lo que las cosas podrían haber cambiado).

Sí, yo (um, we) lo usamos ampliamente para modelar nuestra lógica de proceso de negocio que era principalmente formularios de datos en una aplicación de formularios de Windows. La aplicación era un sistema de comercio. CSLA está diseñado para estar en esa capa justo debajo de la IU.

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 las reglas de validación de campo cruzado), puede invocar un diálogo modal para editar algún objeto hijo, puede desea poder cancelar dichos diálogos y volver a un estado anterior. CSLA apoya esto.

Las desventajas son que tiene un poco de una curva de aprendizaje.

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

También consideramos que es muy útil poder utilizar los objetos comerciales de CSLA en el lado del servidor para validar los objetos enviados por los clientes.

También habíamos incorporado mecanismos para realizar la validación de forma asíncrona contra el servicio web (es decir, verificar el rango de límite de crédito de una contraparte frente a un maestro).

CSLA impone una fuerte separación entre su UI, BusinessLogic y Persistance y nosotros escribimos una carga de pruebas unitarias contra ellos. Puede que no sea estrictamente TDD porque lo está impulsando 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 termina implementando características que CSLA ofrece de manera predeterminada (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState, etc.)

Tuve experiencia con esto hace varios años. Es una arquitectura brillante, pero muy compleja, difícil de entender o cambiar, y está solucionando un problema que la mayoría de nosotros en desarrollo de aplicaciones basadas en web no necesariamente tiene. Fue desarrollado más para aplicaciones basadas en Windows y manejo de deshacer de varios niveles, con un fuerte énfasis en la lógica transaccional. Probablemente escuche a la gente decir que dado que las aplicaciones web son de solicitud y respuesta a nivel de página, no es apropiado, pero con las aplicaciones web de estilo AJAX quizás este argumento no contenga tanta agua.

Tiene un modelo de objetos muy profundo, y puede tomar un tiempo realmente envolver su cerebro alrededor de él. Por supuesto, mucho puede cambiar en unos años. Me interesaría escuchar otras opiniones recientes.

Teniendo en cuenta todo, no sería mi primera elección de arquitectura.

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

Lo usé para un proyecto hace un par de años. Pero cuando el proyecto finalizó, 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 reestructuración. No teníamos ningún uso para las cosas N-Tier. El deshacer de nivel n fue tan lento que no pudimos usarlo. Así que supongo que al final solo nos ayudó a modelar nuestras clases.

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

Quería usarlo, pero mi desarrollador líder en ese entonces tenía la idea de que había mucha ''magia'' involucrada ...

He usado CSLA para un proyecto y funcionó de maravilla y simplificó mucho las cosas.

En lugar de tener a su equipo escribiendo objetos comerciales en su propio estilo personal, sabemos que tenemos un estándar común contra el cual trabajar.

// andy

Usamos CSLA extensivamente. Hay varios beneficios; Primero, creo que cada línea de desarrollador de negocios debe leer el libro de Rocky Lhotka sobre la programación de Business Objects. Personalmente, me pareció estar entre mis mejores 3 libros de programación. CSLA es un marco basado en este libro y usarlo le da a su proyecto acceso a funcionalidades de muy alto nivel como deshacer n nivel, reglas de validación y arquitectura de escalabilidad al mismo tiempo que proporciona los detalles para usted. Observe que dije "proporcionar" y no "ocultar". Descubrí que la mejor parte de CSLA es que te hace comprender cómo se implementan todas estas cosas hasta el código fuente sin que sea necesario que las reproduzcas tú mismo. Puede optar por usar tantas o pocas funciones como necesite, pero he descubierto que si me mantengo fiel a los patrones de diseño del marco, realmente lo mantendrá alejado de problemas. --Byron

Soy un tipo PHP. Cuando comenzamos a desarrollar aplicaciones comparativamente a gran escala con PHP, comencé a investigar en muchos frameworks de aplicaciones y ORM esencialmente en PHP World, luego en Java y .NET. La razón por la que también analicé los frameworks .NET y Java no fue utilizar ciegamente ningún framework PHP, sino primero tratar de entender qué está pasando 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 ventajas y desventajas, pero lo que puedo decir es que Lhotka es uno de los pocos pensadores -no estoy diciendo simplemente experto- en el campo de la arquitectura de software. Aunque el nombre de Domain Driven Design lo acuñó Eric Evans -por la forma en que su libro también es excelente y humildemente le aconsejo que lo lea- Lhotka estuvo aplicando el diseño impulsado por el dominio durante años. Una vez dicho esto, sea lo que sea que piense sobre su marco, aproveche sus ideas profundas en el campo.

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

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

En defensa del CSLA, aunque estoy de acuerdo con muchos de los comentarios que se han hecho particularmente la unidad de prueba de uno ...

Mi compañía lo usó extensivamente 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 o la experiencia para escribirnos.
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 ha sido superado por los beneficios.

ACTUALIZACIÓN: Además de esto, todavía lo estamos utilizando para nuestra aplicación de formularios de Windows, pero los experimentos con su uso para otras aplicaciones, como los sitios web, han demostrado que es engorroso cuando no necesita mucha de su funcionalidad y ahora estamos investigando opciones de peso más ligero para estos escenarios.

No tomar CSLA de la lista, pero antes de usarla, investigue los beneficios y asegúrese de que realmente se apliquen. ¿Su equipo podrá implementarlo correcta / consistentemente? Remoting y portal dance necesarios?

Creo que más allá de todo el ponderador teórico, se trata de un código limpio / mantenible / extensible / comprobable que sigue patrones básicos comprobados.

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

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

¡Aclamaciones!

John,

Tenemos equipos trabajando en CSLA de 2 a 3.5 y hemos encontrado que es una gran manera de proporcionar un marco constante para que todos los desarrolladores "lo hagan de la misma manera". Es genial que se genere la mayor parte del código de bajo valor y sabemos que cuando realizamos pruebas unitarias, funcionan de la caja para todas las cosas de 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.

Chris

La última vez que intenté usar CSLA fue en los días de la edad de piedra de VB6. En retrospectiva, hubiera sido más efectivo si hubiera usado 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 características que obtiene de CSLA no compensarán la cantidad de tiempo que pasa escribiendo n líneas de código por tabla, n líneas de código por columna, etc.

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

Pros:

Tecnología de datos agnóstica ¹
¡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 ensamble separado
Validación y Autorización de Propiedades y Objetos

Contras

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

No estoy seguro sobre el diseño impulsado por la prueba. No realizo pruebas unitarias o pruebas de diseño (es una pena para mí), así que no sé si las pruebas unitarias son diferentes a TDD, pero sé que la versión más reciente del marco viene con pruebas unitarias.

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

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

Primero, CSLA no es un ORM . ¿Cómo puedo decir eso tan definitivamente? Porque Rockford Lhotka lo ha declarado muchas veces en entrevistas en los podcasts .NET Rocks y Hanselminutes . Busque cualquier episodio en el que se entrevistó a Rocky y lo dirá en términos muy claros. Creo que este es el hecho más crítico para que las personas entiendan, porque casi todos los conceptos erróneos sobre CSLA se derivan de creer que se trata de un ORM o de intentar usarlo como uno solo.

Como Brad Leach aludió en su respuesta, CSLA objeta el comportamiento del modelo, 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 habla con su almacén de datos. Debería usar algún tipo de capa de acceso a datos con CSLA, quizás incluso un ORM. (Sí. Ahora uso Entity Framework, que funciona muy bien).

Ahora, a prueba unitaria. Nunca tuve dificultades para probar mis objetos CSLA, porque no puse mi código de acceso a datos directamente en mis objetos comerciales. En cambio, uso alguna variación del patrón de repositorio. El repositorio es consumido por CSLA, no al revés. Al intercambiar en un repositorio falso para mis pruebas unitarias y usar el portal de datos local, ¡BOOM! es sencillo. (Una vez que Entity Framework permite el uso de POCO, esto será aún más limpio).

Todo esto proviene de darse cuenta de que CSLA no es un ORM. Puede consumir un ORM, pero en sí mismo no es uno.

Aclamaciones.

ACTUALIZAR

Pensé que haría 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 lo hace, como la validación integrada y la persistencia n -tier a través de varios portales de datos remotos. De hecho, diría que lo último, la persistencia n- tercia, los supera a todos por mí. Si quiero usar Entity Framework o LINQ to SQL en la red, tengo que poner algo como WCF en el medio, y eso multiplica enormemente el trabajo y la complejidad, hasta el punto en 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 negocio, no es realmente es necesario, y CSLA es una mejor opción.) De hecho, con la última versión de CSLA, Rocky proporciona un WCFDataPortal , que he usado. Funciona muy bien.

Soy fanático de SOLID , TDD y otros principios modernos de desarrollo de software, y los utilizo 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 hacer que CSLA funcione bastante bien (y fácilmente) con TDD, así que eso no es un problema.

He usado CSLA.NET en algunos proyectos ahora, fue más exitoso en una aplicación de formularios de Windows que tiene una gran compatibilidad de enlace de datos (que las aplicaciones asp.net no tienen).

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

Nuestra compañía 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 simple y simple de OOP: Principio de responsabilidad única.

Los objetos de CSLA son autosuficientes, por ejemplo, recuperan sus propios datos, administran su propio comportamiento, se salvan a sí mismos. 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 dije / implícito anteriormente) al mismo tiempo hora.

CSLA es el mejor marco de aplicación 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.

He estado usando CSLA desde vb5, cuando era más una colección de patrones que un framework. Con la introducción de .NET, CSLA se convirtió en un marco completo, que venía con una gran curva de aprendizaje. Sin embargo, el CSLA aborda muchas cosas que todos los desarrolladores de negocios tienden a escribir 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 del caja en un marco agradable.

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

De hecho, yo diría que la razón por la cual tantos de estos patrones de UI están tan promocionados hoy (en el mundo de Microsoft) es que las personas han estado haciendo cosas increíblemente incorrectas durante tanto tiempo (es decir, usando DataGrids en su UI, rociando su lógica de negocios en todas partes. tisk tisk). Diseñe su nivel medio (lógica comercial) correctamente desde el principio, puede reutilizar su nivel intermedio en CUALQUIER UI. Win Form, ASP.NET/MVC, WCF Service, WPF, Silverlight **, Servicio de Windows, ....

Pero aparte de esto, la gran recompensa para mí ha sido su capacidad integrada 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 servidor a servidor, sin tener que escribir una sola palabra de código. ¿Agregar más usuarios a tu sistema? No hay problema, despliegue sus objetos comerciales CSLA en un nuevo servidor de aplicaciones, realice un cambio en la entrada del archivo de configuración y ¡BAM! Necesidades de escalabilidad instantánea satisfechas.

Compare esto con el uso de DTO, almacenando su lógica de negocio en el cliente (sea cual sea el cliente), y tenga que escribir cada uno de sus propios métodos CRUD como métodos de servicio. YIKES !!! No digo que este sea un mal enfoque, pero no me gustaría hacerlo. No cuando hay un marco para esencialmente hacerlo por mí.

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

En cuanto a su soporte para TDD, nunca intenté usar ese enfoque con CSLA tampoco. Tomé el enfoque en el que modelé mi nivel medio (objetos comerciales ala) utilizando diagramas de clases y secuencias, lo más a menudo posible para dictar el caso de uso, la pantalla y / o el diseño del proceso. Tal vez un poco vieja escuela, pero UML siempre me ha servido muy bien en mis esfuerzos de diseño y desarrollo. He diseñado y desarrollado con éxito aplicaciones muy grandes y escalables que aún se utilizan en la actualidad. Y hasta que WCF RIA madure, continuaré usando CSLA ...

** con algo de trabajo alrededor

Mucha gente recomienda usar Code Generation con CSLA. Recomiendo consultar nuestro conjunto de plantillas compatibles, ya que aumentarán su ROI inmensamente.

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

Soy nuevo en CSLA, pero entiendo los conceptos y ya entiendo que no es una herramienta de ORM, así que deja de ganarle a esa maldita batería. Hay características de CSLA que me gustan pero usarlas parece un poco como si hubiera un mago detrás de la cortina. Supongo que si no te importa no saber cómo funciona, entonces puedes usar los objetos y funcionan bien.

Hay una gran curva de aprendizaje para principiantes y creo que se beneficiaría enormemente al tener 5-15 min. videos como Microsoft tiene para aprender los fundamentos. ¿O qué tal si lanzamos un libro complementario con el código en lugar de publicar el código y tardamos meses en sacar el libro? Solo digo Sr. Lohtka ... Empezamos a construir nuestras cosas antes del libro y luché todo el tiempo. Pero como dije, soy nuevo en eso.

Usamos CSLA. Hicimos que nuestros objetos se ajustaran a su molde y luego usamos el 10% de lo que ofrecía el marco. Nivel de objeto deshacer? No lo uso. ¿Mayor flexibilidad? No lo uso. Terminamos escribiendo suficiente código de regla empresarial que pensé que lo único que estábamos sacando de CSLA era la complejidad. Algunos desarrolladores de "long in the tooth" que saben que el framework lo usó como su martillo porque tenían un clavo que necesitaba golpear. CSLA estaba en su cinturón y creo que muchos defensores del marco también ven las cosas desde esa perspectiva.

Supongo que nuestros experimentados desarrolladores están felices porque todo tiene sentido para ellos. Supongo que si su organización no tiene programadores novatos y ustedes se aburren escribiendo objetos POCO eficientes y simples con patrones bien formados, entonces pruébenlos. Use CSLA.

Me uní a un equipo donde CSLA es obligatorio. No usamos el portal de datos remoto, que es la única razón por la que podría aceptar el uso de este marco. Nunca creí en la idea de CSLA, así que quizás es por eso que no tengo nada más que problemas, lo siento.

Algunos de los problemas:

No necesito un bloqueo de ruta entre mi código y el .NET framework, que es lo que este framework me pareció. Tenía una opción limitada de objetos de lista, mientras que simplemente tenía que ignorar los objetos de la lista enriquecida en .NET Framework.

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

Entonces csla quiere administrar mi estado de objeto, que está bien, pero nada está realmente expuesto. A veces quiero cambiar el estado de un objeto manualmente en lugar de volver a buscarlo, lo que parece ser lo que csla quiere que haga. Básicamente, terminé creando muchas propiedades para exponer opciones a las que csla no creía que debería tener acceso directo.

¿Por qué no puedo simplemente crear una instancia de un objeto? Terminamos creando métodos estáticos que ejemplifican un objeto y lo devuelven ... ¿me estás tomando el pelo?

Comprueba el código fuente del framework y me parece muy pesado en el código de reflexión.

Razones para usar csla:

el framework straight .net es demasiado poderoso para ti.
sus desarrolladores no están experimentados y no pueden comprender el concepto de patrones, entonces csla casi tendrá a todos en la misma página.
1. No necesito un bloqueo de ruta entre mi código y el .NET framework ... Estoy atascado con estos objetos de lista.