architecture hashtags instagram
¿Qué es el software valorado? (9)
El ejemplo que verá mucho en este momento es el marco MVC de ASP.NET. Es increíblemente extensible, pero eso es su caída en algunos aspectos, no hay nada de eso. ¿Quieres hacer acceso a los datos? Tendrás que escribir eso tú mismo. ¿Quieres un poco de AJAX? Ídem.
Sin embargo, como es altamente extensible, si se construye sobre él, puede convertirlo en un marco de opinión. Esto es lo que hacen los gustos de MVCContrib , te dan métodos específicos para hacer las 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 que hacer que si estuviera trabajando en la versión de vainilla. Este es un escenario 80/20 sin embargo. Si elige su marco de opinión correctamente, solo querrá romper con las opiniones el 20% del tiempo y será altamente productivo el otro 80% del tiempo.
A menudo veo personas que dicen que cierto software es "muy criticado" o que Microsoft tiende a escribir frameworks "no opinados". ¿Qué significa esto realmente?
El software de opinión está construido y diseñado de tal manera que hace que sea fácil hacer las cosas de cierta manera. Favorece ciertos patrones de diseño más que otros. En el proceso, hace que sea difícil desviarse del estilo de desarrollo de software para el que se desarrolló. 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 de opinión generalmente es más rápido de dominar una vez que se comprenden las suposiciones.
Por otra parte, el software no respaldado hace pocas suposiciones. Y como resultado, los marcos de desarrollo de software / software que no están patrocinados a menudo tienden a tener muchas opciones de configuración. Un desarrollador normalmente tiene que tomar muchas decisiones con respecto a varios aspectos del software. A menudo, se desarrollan varias herramientas para facilitar el manejo de estas enormes opciones. por ejemplo, Visual Studio .NET para .NET, Eclipse IDE para Java, etc. El software no dotado normalmente requiere más tiempo para dominarlo que el software de opinión.
El software de opinión significa que básicamente hay una manera (la manera 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 hacer que el desarrollo del software sea muy fácil, ya que se reduce la cantidad de decisiones que tiene que tomar y la capacidad de los diseñadores de software para concentrarse en hacer que el software funcione. El software de opinión puede ser excelente para usar, si se hace bien, si su problema se relaciona muy bien con la solución. Puede ser un verdadero problema resolver las partes de su problema que no se relacionan con las herramientas provistas. Un ejemplo aquí sería Ruby on Rails.
El software sin opiniones, 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 utilizar 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 a mano mucha más solución porque el marco no proporciona suficiente ayuda. También debe 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 de opinión. PERL es probablemente el ejemplo clásico de software sin opiniones.
Mi ideal es un marco sin opiniones, pero con convenciones sólidas. Yo pondría a ASP.NET MVC en esta categoría. En realidad, todo el software tiene cierta opinión (aunque quizás no sea PERL). MVC tiene convenciones sólidas en su elección de modelo, pero ofrece muchas maneras diferentes de resolver problemas dentro de esas convenciones. Algunas de esas formas pueden incluso romper el modelo. Sin embargo, el uso correcto, de acuerdo con las convenciones que se desarrollan en dicho marco, puede ser una verdadera alegría.
Es básicamente un software que funciona de la forma en que sus autores piensan que debería funcionar, en lugar de intentar complacer a todos. Eso significa que a mucha gente no le va a gustar, pero a los que lo hagan les encantará.
Rails es probablemente el ejemplo canónico de un marco de opinión: haces las cosas a su manera y todo es suave. Si no lo haces, te espera un poco de dolor. Pero está bien: si no quieres hacer las cosas a su manera, no quieres usar Rails.
Es la cantidad de convenciones implementadas en un marco y la cantidad de decisiones que se han tomado.
Si, por ejemplo, hay 5 (o más) formas diferentes de enviar datos del formulario a una acción del controlador (como es el caso en ASP.NET MVC), el marco parece ser bastante "indiferente": la decisión está en marcha. ¡para ti!
Sin embargo, si el marco habilita (ya sea desactivando directamente otras formas, o alentándolo fuertemente) solo una manera de hacer eso (lo cual es el caso de Fubu MVC), podría decir que la decisión ha sido tomada por el marco. , haciendo así el marco opinado.
Mucha gente está haciendo referencia a ASP.NET MVC como un marco de trabajo "no motivado", y solo quería comentarlo con un par de pensamientos.
Es cierto que ASP.NET MVC no exige demasiado; Puede usar cualquier solución de persistencia que desee, ya sea de 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 en gran medida seguir el patrón predefinido para ubicar controladores, vistas, modelos y otros códigos. Aunque puede modificar este comportamiento, es más fácil nadar con la corriente, y para la mayoría de las personas, no hay problema en hacerlo.
También rodean a ASP.NET MVC muchas personas de opinión, lo que creo que conduce a muchos tutoriales sesgados que insisten en cubrir, por ejemplo, pruebas de unidad e inyección de dependencia; Estoy a favor de las buenas pruebas y la separación de las preocupaciones, pero sí percibo que esos temas se ponen un poco en la garganta, a menudo antes de cubrir conceptos básicos más útiles.
De nuevo, tengo que admitir que dentro de esas áreas, el marco mismo está completamente abierto para adoptar cualquier solución de prueba unitaria que desee, así como cualquier marco de inyección de dependencia y simulacro que desee utilizar, así que supongo que eso proporciona otro ejemplo de flexibilidad, incluso dentro del "ataque a la biblia" de las pruebas unitarias, etc., que parece estar ocurriendo.
Por el bien del equilibrio, proporcionaré una descripción (más bien de opinión) que sea más favorable al enfoque de opinión (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 significa necesariamente encerrado. Esto significa que puede requerir un esfuerzo extra para hacer las cosas de manera diferente.
Los marcos con menos opiniones proporcionan una serie de opciones diferentes y le permiten a usted decidir.
Los marcos de opinión por lo general eliminan la carga del desarrollador para reinventar la rueda o repensar el mismo problema una y otra vez y así ayudar a concentrarse en el problema real en cuestión.
En el mundo de código abierto, puede encontrar muchos marcos opuestos pero competidores, por lo que aún tiene una opción. Solo tienes que elegir tu propio camino de oro.
Si se opone a un marco, lo encierra o lo guía en su forma de hacer las cosas.
Por ejemplo: algunas personas creen que un sistema de plantillas no debe proporcionar acceso a los métodos y funciones definidos por el usuario, ya que deja el sistema abierto para devolver HTML en bruto. Por lo tanto, un desarrollador de marcos de opinión solo permite el acceso a estructuras de datos Por diseño, el software limita 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. Pensaron que el HTML era demasiado complicado para que las personas escribieran, por lo que se les ocurrió lo que consideraban una forma más natural de actualizar el contenido. También lo despojaron del diseño sofisticado porque sentían que el enfoque debí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 que tome las decisiones correctas y pone más control en sus manos.
También pondría a Microsoft en la columna sin opiniones. Un buen ejemplo de un marco de trabajo de Microsoft que no es de opinión: .NET . Al abrir el CLR y las especificaciones, lo abrió a todo tipo de lenguajes y estilos de implementación.
tl; dr :
- Opinado : por ejemplo, Ruby on Rails . Hay una forma particularmente preferida de hacer las cosas, y usted recibe mucho apoyo para hacer las cosas de esa manera. Hacer cosas de otras maneras es difícil, o para algunos sistemas imposibles (Cassandra viene a la mente).
- Sin opiniones : por ejemplo, Perl 5 . Puedes hacer lo que quieras, como quieras, en cualquier estilo. Todos los estilos son igualmente abiertos, válidos y compatibles.