tutorial net framework nhibernate orm csla

nhibernate - net - ¿Alguna vez ha usado CSLA?



nhibernate vs entity framework (5)

Posible duplicado:
¿Alguien tiene alguna experiencia real de CSLA?

¿Alguna vez ha usado CSLA y, de ser así, cuáles son sus pensamientos? Estoy comenzando un nuevo contrato para una compañía que usa CSLA y NHibernate y quería algunas opiniones o puntos de vista sobre el marco.


Lo usamos en un escenario basado en web y en un escenario de escritorio. Me fui (por otras razones) antes de implementar los proyectos, pero escuché que el proyecto basado en la web fue un éxito. Creo que CSLA ayudó a dar una consistencia general al proyecto en términos de los objetos de dominio, pero como otros han dicho en el otro hilo, muchas de las características no son tan útiles en una aplicación desconectada como una aplicación web.


Mi opinión:

  • El libro es excelente Me enseñó mucho sobre .NET y el diseño en general
  • No estoy de acuerdo con el diseño de CSLA, por lo tanto, nunca lo usaría :)

Toma las ideas y usa lo que es valioso para ti. CSLA no se sostiene por sí solo como un ORM, solo proporciona el marco de objetos. Es completamente aceptable escribir el suyo (si es que lo necesita).


CSLA se utiliza en nuestra compañía en todo el mundo. Personalmente lo he usado para desarrollar sitios web, servicios web, aplicaciones de cliente enriquecido, etc.

En una aplicación en particular que utiliza CSLA, nos hemos desplegado en Asia, Europa, los sitios en los EE. UU. Y los sitios en el mar en los barcos.

CSLA aísla a los desarrolladores de los problemas del .Net Framework y la siempre cambiante topología arquitectónica de Microsoft. Es lo suficientemente potente y flexible como para resolver casi todos los requisitos que tenga, pero lo suficientemente fácil de mantener y desarrollar, ya que su código siempre será mantenible y soportable incluso por algunos de sus desarrolladores más jóvenes.

Nuestra corporación se extiende por todo el mundo, y no pensaría en desarrollar nuestras aplicaciones sin ella ... dados los parámetros adecuados (es decir, no desarrollaré un sistema de orientación de misiles con ella). Como con todas las cosas, se inteligente.

Usar CSLA te pondrá exactamente donde necesitas estar.


CSLA es genial. Lo he estado usando durante varios años. Sin embargo, ahora que WCF y REST están por ahí han eliminado una gran parte de la razón por la que uno querría usar CSLA. A menos que realmente necesite un fuerte soporte de enlace de datos limpio / sucio para su UI y / o deshacer niveles para cambios en sus objetos, consideraría seriamente WCF y REST ya que es un estándar más abierto para la abstracción de capas de acceso a datos.

Habiendo dicho eso, estamos preparados para la versión 3.6 de CSLA y todavía nos ofrece un gran valor para nuestras aplicaciones de línea de negocios.


Sí, al hacer la pregunta original a la que se refiere Galwegian , puedo brindarles mis experiencias hasta ahora. Actualmente estoy usando CSLA para salvar los restos de una aplicación de lob interna de asp.net. Lo he seleccionado porque tiene reglas de autorización y comerciales, somos un equipo pequeño y no tenemos el lujo del tiempo para rodar mis propios objetos de negocios.

Para lo que lo usamos ... hasta ahora todo bien. Mucha gente ha comentado que el trabajo de marco es demasiado complicado. Realmente no he encontrado esto todavía. El mayor salto que encontré en mi experiencia de aplicaciones empresariales es que el acceso a los datos está estrechamente vinculado a la lógica. (Esta es la visión de Rocky sobre la encapsulación). Nosotros (mi equipo) estamos descubriendo que esto alienta a escribir integración en lugar de pruebas unitarias.

Para construir objetos de negocio hay mucho trabajo pendiente que debe hacerse y esto debe ser abordado por un generador de código. (No estoy usando uno aunque todavía quiero obtener un control del marco) La última versión de CSLA (3.5) reduce la cantidad de código en propiedades y nos hemos actualizado debido a esto.

Otros aspectos destacados son SmartDate y SafeDataReader.