Respuestas:
Si un marco es obstinado, lo bloquea o lo guía en su forma de hacer las cosas.
Por ejemplo: algunas personas creen que un sistema de plantillas no debería proporcionar acceso a métodos y funciones definidos por el usuario, ya que deja el sistema abierto para devolver HTML sin formato. Por lo tanto, un desarrollador de marcos obstinado solo permite el acceso a las estructuras de datos. Por diseño, el software es limitante y alienta al diseñador a hacer las cosas a su manera.
Otro ejemplo ( tomado del enlace de señales ) es el de wiki . Los diseñadores de wiki tenían muchas opiniones. Pensaban que HTML era demasiado complicado para que la gente lo escribiera, por lo que se les ocurrió lo que sentían que era una forma más natural de actualizar el contenido. También lo despojaron del diseño elegante porque sentían que el enfoque debería estar más en el contenido que en el diseño.
Apple tiene fuertes opiniones cuando diseña sus productos.
El diseño de software sin opiniones es más parecido a PERL / PHP. Permite al desarrollador y confía en el desarrollador para tomar las decisiones correctas y pone más control en sus manos.
También colocaría a Microsoft en la columna no obstinada. Un buen ejemplo de un marco de Microsoft, que es un-opininated: .NET. Al abrir el CLR y las especificaciones, lo abrió a todo tipo de lenguajes y estilos de implementaciones.
El software con opiniones significa que básicamente hay una manera (la forma correcta ™) de hacer las cosas y tratar de hacerlo de manera diferente será difícil y frustrante. Por otro lado, hacer las cosas de la manera correcta ™ puede facilitar el desarrollo con el software, ya que se reduce la cantidad de decisiones que debe tomar y aumenta la capacidad de los diseñadores de software para concentrarse en hacer que el software funcione. El software con opiniones puede ser excelente para usar, si se hace bien, si su problema se adapta bien a la solución. Puede ser un verdadero dolor resolver aquellas partes de su problema que no se asignan a las herramientas proporcionadas. Un ejemplo aquí sería Ruby on Rails.
El software no obstinado, por otro lado, deja mucha flexibilidad al usuario (desarrollador). No proscribe un método para resolver un problema, pero proporciona herramientas flexibles que se pueden usar para resolver el problema de muchas maneras. La desventaja de esto puede ser que debido a que las herramientas son tan flexibles, puede ser relativamente difícil desarrollar cualquier solución. Es posible que el usuario (desarrollador) tenga que codificar mucho más la solución porque el marco no proporciona suficiente ayuda. También tiene que pensar mucho más sobre cómo proporcionar una solución y los desarrolladores mediocres pueden terminar con soluciones más pobres que si hubieran comprado algún software obstinado. PERL es probablemente el ejemplo clásico de software no obstinado.
Mi ideal es un marco no obstinado, pero con convenciones fuertes. Pondría ASP.NET MVC en esta categoría. En realidad, todo el software es obstinado hasta cierto punto (aunque quizás no sea PERL). MVC tiene convenciones fuertes en su elección de modelo, pero ofrece muchas formas diferentes de resolver problemas dentro de esas convenciones. Algunas de esas formas pueden incluso romper el modelo. Sin embargo, si se usa correctamente, de acuerdo con las convenciones que se desarrollan en dicho marco, puede ser una verdadera alegría.
Básicamente es un software que funciona de la forma en que sus autores piensan que debería funcionar, en lugar de tratar de complacer a todos. Eso significa que a mucha gente no le gustará, pero a los que sí les va a encantar.
Rails es probablemente el ejemplo canónico de un marco obstinado: haces las cosas a su manera, y todo es sencillo. Si no lo haces, te dolerá un poco. Pero está bien: si no quieres hacer las cosas a su manera, no quieres usar Rails.
En aras del equilibrio, proporcionaré una descripción (bastante obstinada) que sea más favorable al enfoque obstinado (en contraste con algunas de las otras respuestas).
Los marcos de opinión proporcionan un "camino de oro", que se supone que es la mejor práctica para la mayoría de las personas y la mayoría de los escenarios (a los ojos de los autores).
Sin embargo, esto no necesariamente significa bloqueo. Significa que puede requerir un esfuerzo extra para hacer las cosas de manera diferente.
Los marcos menos obstinados brindan una variedad de opciones diferentes y le deja a usted decidir.
Los marcos de opinión habitualmente eliminan la carga del desarrollador para reinventar la rueda o repensar el mismo problema una y otra vez y, por lo tanto, ayudan a centrarse en el problema real en cuestión.
En el mundo de código abierto, puede encontrar muchos marcos obstinados pero competitivos, por lo que todavía tiene una opción. Solo tienes que elegir tu propio camino dorado.
El software de opinión está construido y diseñado de tal manera que facilita hacer las cosas de cierta manera. Favorece ciertos patrones de diseño más que otros. En el proceso, es difícil desviarse del estilo de desarrollo de software para el que fue desarrollado. Otra forma de decirlo es que favorece la "Convención sobre la configuración". es decir, las opciones de configuración son muy limitadas ya que el software asume muchos de los aspectos de configuración. El software con opiniones generalmente es más rápido de dominar una vez que se entienden los supuestos.
Por otro lado, el software no pionero hace pocas suposiciones. Y como resultado, los marcos de desarrollo de software / software que no son opinados suelen tener muchas opciones de configuración. Un desarrollador generalmente tiene que tomar muchas decisiones con respecto a varios aspectos del software. A menudo, se desarrollan diversas herramientas para facilitar el manejo de estas enormes opciones. por ejemplo, Visual Studio .NET para .NET, Eclipse IDE para Java, etc. El software sin espino suele tardar más en dominar que el software con opiniones.
tl; dr :
Mucha gente hace referencia a ASP.NET MVC como un marco "no opinado", y solo quería opinar con un par de ideas al respecto.
Es cierto que ASP.NET MVC no exige demasiado; puede usar cualquier solución de persistencia que desee, ya sea Linq-to-SQL, ADO.NET Entities, NHibernate, etc.
Por otro lado, el marco MVC tiende a favorecer la "convención sobre la configuración", para citar a Phil Haack, que sugiere seguir el patrón predefinido para localizar controladores, vistas, modelos y otro código. Aunque puede alterar este comportamiento, es más fácil nadar con la corriente, y para la mayoría de las personas, no hay problema para hacerlo.
También alrededor de ASP.NET MVC hay muchas personas obstinadas, lo que creo que lleva a muchos tutoriales sesgados que insisten en cubrir, por ejemplo, pruebas unitarias e inyección de dependencia; Estoy a favor de las buenas pruebas y la separación de las preocupaciones, pero sí percibo que tales temas se presionan un poco, a menudo antes de cubrir conceptos básicos más útiles.
Una vez más, debo admitir que dentro de esas áreas, el marco en sí está completamente abierto a adoptar cualquier solución de prueba de unidad que desee, así como cualquier inyección de dependencia y marcos de burla que desee usar, por lo que supongo que eso proporciona otro ejemplo de flexibilidad, incluso dentro del "ataque bíblico" de las pruebas unitarias, etc.
Es la cantidad de convenciones implementadas en un marco y el número de decisiones que se han tomado.
Si, por ejemplo, hay 5 (o más) formas diferentes de enviar datos de formulario a una acción del controlador (que es el caso en ASP.NET MVC), el marco parece ser bastante "poco obstinado": la decisión está pendiente ¡para ti!
Sin embargo, si el marco permite (ya sea inhabilitando directamente otras formas o alentándolo fuertemente) solo una forma de hacer eso (que es el caso con Fubu MVC), se podría decir que la decisión ha sido tomada por el marco , haciendo que el marco sea obstinado.
El ejemplo que verá mucho en este momento es el framework ASP.NET MVC. Es increíblemente extensible, pero esa es su caída en algunos aspectos, no tiene nada de carne. ¿Quieres hacer acceso a datos? Tendrás que escribir eso tú mismo. ¿Quieres algo de AJAX? Ídem.
Sin embargo, como es altamente extensible, si se basa en él, puede convertirlo en un marco obstinado. Esto es lo que hacen los gustos de MVCContrib , te dan métodos específicos para hacer cosas, lo que significa que tienes que escribir menos código.
Esto significa que si quiere romper con la opinión, a menudo hay más trabajo por hacer que si estuviera trabajando en la versión estándar. Sin embargo, este es un escenario 80/20. Si elige correctamente su marco de opinión, solo querrá romper con las opiniones el 20% del tiempo y será altamente productivo el otro 80% del tiempo.