T4 vs CodeDom vs Oslo [cerrado]

Question

En un proyecto de andamios de aplicaciones en el que estoy trabajando, estoy tratando de decidir si usar Oslo , T4 o CodeDom para generar código. Nuestros objetivos son mantener las dependencias al mínimo e impulsar la generación de código para un diseño impulsado por dominio a partir de historias de usuarios. El primer paso será crear las pruebas a partir de las historias de los usuarios, pero queremos que los expertos en dominios puedan escribir sus historias en una variedad de medios diferentes (por ejemplo, aplicaciones personalizadas, Word, etc.) y aún generar las pruebas a partir de historias.

Lo que sé hasta ahora:

1. CodeDom requiere .NET pero solo puede generar archivos de clase .NET (por ejemplo, .cs, .vb). El nivel de dificultad es bastante alto.
2. T4 requiere CodeDom y VS Standard +. El nivel de dificultad es bastante razonable, especialmente con el T4 Toolbox .
3. Oslo es muy nuevo. No tengo idea de las dependencias, pero imagino que debe estar en al menos .NET 3.5. Tampoco estoy seguro de las capacidades de generación de código o la complejidad para agregar nuevas gramáticas. Sin embargo, los expertos en dominios probablemente podrían escribir historias de usuarios en Intellipad con bastante facilidad. Tampoco estoy seguro de la facilidad de convertir historias en Word a un MGrammar.

¿Cuáles son sus pensamientos, experiencias, etc. con cualquiera de las herramientas anteriores? Queremos seguir con Microsoft o herramientas de código abierto.

Answer 1

Ve con T4 - decisión fácil.

• Oslo es demasiado nuevo y las herramientas son demasiado crudas para ser algo más que una tecnología eval-only
• CodeDOM es potente, si necesita generar clases CLR en tiempo de ejecución, y está dispuesto a sacrificar modificaciones fáciles a su salida generada.
• T4 (con el kit de herramientas T4) es una herramienta de generación de código de uso general fácil de usar. La única dificultad que he tenido hasta ahora es en las integraciones de tiempo de construcción.

Answer 2

En términos generales, veo la generación de código como parte de una historia completa de modelado / codificación. Debe ir acompañado de un marco genérico en el que se realiza la mayor parte de la fontanería. En mi opinión, no es útil generar clases enormes, mientras que un marco decente con puntos de extensión o ganchos bien definidos será mucho mejor para mantener y ampliar.

Deberá definir un lenguaje formal para las historias de los usuarios, ya sea XML o un idioma de dominio de Oslo. Oslo requeriría que sus expertos en dominios aprendan las herramientas de Oslo. Podrías usar Word + XML. Luego, define una plantilla atractiva en Word, con un esquema XML incrustado y, una vez escrita la historia, puede obtenerla de Word en una sintaxis XML formalizada. Este XML, por supuesto, puede usarse para generar generadores, a través de XSLT o Linq.

CodeDOM es poderoso, pero bastante engorroso. En mi humilde opinión, no es una solución fácil de usar y no tiene soporte de plantilla real.

No tengo experiencia con T4, pero sus características de plantilla son pre.

El producto de Oslo es bastante nuevo, requiere .Net 4.0, un entorno de tiempo de ejecución. Todavía es solo un CTP. Es un entorno muy poderoso, aunque tengo algunas dudas sobre la historia de generación de la base de datos.

Espero que esto ayude.

Answer 3

Bueno, Oslo no encaja en la lista. No tiene una historia de generación de código hasta el momento. Así que quédate con T4.

Answer 4

Oslo no tiene la intención de generar código para usted. Deberá crear un tiempo de ejecución (programa C #, por ejemplo) que cambie su comportamiento en función de los datos. Puedes verlo como un navegador de internet.

No creo que Oslo requiera un .Net 4.0, como menciona Rine. Para mi pasantía en Avanade Netherland, yo & # 8217; estoy creando Oslo MSchema y MGrammars y un tiempo de ejecución C # 3.5. Dependiendo de los datos proporcionados, creará (no generará) servicios WCF y los ejecutará.

Answer 5

Hay algunas aplicaciones interesantes de Oslo

• el " nuevo LDAP " System.Identity, más en el video de sesión PDC http://microsoftpdc.com/Sessions/SVC28
• System.Modelling (creo) Microsoft.UML2 donde puede enviar información sobre métodos, clases, módulos, etc. en el repositorio, analizarla y crear informes. Por ejemplo, cree un informe con métodos agregados / eliminados entre 2 elementos http://microsoftpdc.com/Sessions/SVR19
• y por supuesto modelado