Al principio era escéptico, pero ahora uso Dynamic Data casi tanto como lo hago con los sitios "estándar" de ASP.NET. Fuera de la caja, es bastante genérico, pero es personalizable, y puede incluir páginas ASP.NET estándar en él.
Al principio, lo usaría como un sitio de administración separado cuando necesitaba una "puerta de atrás" en los datos de una aplicación "estándar". Últimamente, sin embargo, mi enfoque ha sido hacer más planificación y decidir a qué tablas me gustaría que accedan los usuarios a través de los mecanismos de datos dinámicos, y sobre qué datos quiero un mayor control. Puede andamiar solo la tabla que desee, y esto funciona bien para las tablas de "búsqueda" en las que desea que el usuario final pueda agregar/eliminar. Un ejemplo sería en nuestro programa de cupones de correo electrónico, donde los clientes pueden registrarse para recibir cupones por correo electrónico. Pueden elegir sus categorías de cupones: alimentos calientes, bebidas, gas, productos, etc. El administrador del programa de cupones en general debe poder agregar y eliminar categorías, y los datos dinámicos son MARAVILLOSOS para este tipo de cosas.
Los datos dinámicos se encargan de la validación de datos (una gran ventaja para la seguridad Y la usabilidad), mapear nuestras relaciones (un gran ahorro de tiempo) y simplemente "lo hace bien". En el entorno empresarial, la seguridad y la productividad son dos preocupaciones muy reales que la mayoría de los desarrolladores manejan deficientemente, y Dynamic Data parece manejar bien los conceptos básicos.
Así que sí, creo que vale la pena. Es muy poderosa y una herramienta excelente para tener en tu caja de herramientas, pero que debe manejarse con habilidad, lo cual requiere tiempo y práctica. Y no debería ser la única herramienta en su caja de herramientas.
Aclaración menor: 'Ruby! = Rails', pero IMO' Ruby.contains ("el sux") && Rails.contains ("el sux") ' –
Sí, lo siento por no hacer esa distinción. Siento que Rails y Ruby van de la mano, al igual que C# y .NET. –