Respostas:
Se uma estrutura é opinativa, ela trava ou guia você na maneira de fazer as coisas.
Por exemplo: algumas pessoas acreditam que um sistema de modelos não deve fornecer acesso a métodos e funções definidos pelo usuário, pois deixa o sistema aberto para retornar HTML bruto. Portanto, um desenvolvedor de estrutura opinativo permite apenas o acesso a estruturas de dados. Por design, o software é limitador e incentiva o designer a fazer as coisas do seu jeito.
Outro exemplo ( retirado do link de sinais ) é o do wiki . Os designers do wiki tinham muitas opiniões. Eles achavam que o HTML era muito complicado para as pessoas escreverem, então criaram o que consideravam uma maneira mais natural de atualizar o conteúdo. Eles também tiraram o design sofisticado porque sentiram que o foco deveria estar mais no conteúdo do que no design.
A Apple tem opiniões fortes ao projetar seus produtos.
Design de software não opinativo é mais parecido com PERL / PHP. Ele permite que o desenvolvedor e confie no desenvolvedor para tomar as decisões corretas e coloca mais controle em suas mãos.
Eu também colocaria a Microsoft na coluna não opinativa. Um bom exemplo de um quadro Microsoft que é un-opininated: .NET. Ao abrir o CLR e as especificações, ele o abriu para todos os tipos de idiomas e estilos de implementações.
Software opinativo significa que existe basicamente uma maneira (a maneira correta ™) de fazer as coisas e tentar fazer de maneira diferente será difícil e frustrante. Por outro lado, fazer as coisas da maneira certa ™ pode facilitar o desenvolvimento com o software, pois o número de decisões que você precisa tomar é reduzido e a capacidade dos designers de software de se concentrar em fazer o software funcionar aumenta. O software opinativo pode ser ótimo de usar, se bem feito, se o seu problema for direcionado para a solução. Pode ser realmente difícil resolver as partes do seu problema que não são mapeadas para as ferramentas fornecidas. Um exemplo aqui seria Ruby on Rails.
Por outro lado, software não opinativo deixa muita flexibilidade para o usuário (desenvolvedor). Ele não proíbe um método de resolver um problema, mas fornece ferramentas flexíveis que podem ser usadas para resolver o problema de várias maneiras. A desvantagem disso é que, como as ferramentas são muito flexíveis, pode ser relativamente difícil desenvolver qualquer solução. Muito mais da solução pode ter que ser codificado manualmente pelo usuário (desenvolvedor) porque a estrutura não fornece ajuda suficiente. Você também precisa pensar muito mais sobre como fornecer uma solução, e desenvolvedores medíocres podem acabar com soluções mais pobres do que se tivessem comprado em algum software opinativo. PERL é provavelmente o exemplo clássico de software não opinativo.
Meu ideal é uma estrutura não opinativa, mas com fortes convenções. Eu colocaria o ASP.NET MVC nessa categoria. Na realidade, todo software é avaliado até certo ponto (embora talvez não seja PERL). O MVC tem convenções fortes na escolha do modelo, mas oferece muitas maneiras diferentes de resolver problemas dentro dessas convenções. Algumas dessas maneiras podem até quebrar o modelo. No entanto, quando usado corretamente, de acordo com as convenções desenvolvidas em tal estrutura, pode ser uma verdadeira alegria.
É basicamente um software que funciona da maneira que seus autores pensam que deveria funcionar, em vez de tentar agradar a todos. Isso significa que muitas pessoas não vão gostar, mas quem gosta vai adorar.
O Rails é provavelmente o exemplo canônico de uma estrutura opinativa: você faz as coisas do jeito deles, e tudo é tranquilo. Se não, você terá alguma dor. Mas tudo bem - se você não quer fazer as coisas do jeito deles, não quer usar o Rails.
Por uma questão de equilíbrio, fornecerei uma descrição (bastante opinativa) que seja mais favorável à abordagem opinativa (em contraste com algumas das outras respostas).
Estruturas opinativas fornecem um "caminho de ouro", que deve ser a melhor prática para a maioria das pessoas e a maioria dos cenários (aos olhos dos autores).
Isso, no entanto, não significa necessariamente aprisionamento. Isso significa que pode exigir algum esforço extra para fazer as coisas de maneira diferente.
Estruturas menos opinativas fornecem várias opções diferentes e você decide.
Estruturas opinativas geralmente removem a carga do desenvolvedor para reinventar a roda ou repensar o mesmo problema repetidamente e, assim, ajudam a focar no problema real em questão.
No mundo do código-fonte aberto, você pode encontrar muitas estruturas opinativas, ainda que concorrentes, para que ainda tenha uma escolha. Você apenas tem que escolher seu próprio caminho de ouro.
O software opinativo é construído e projetado de tal maneira que facilita as coisas de uma certa maneira. Favorece certos padrões de design mais do que outros. No processo, dificulta o desvio do estilo de desenvolvimento de software para o qual foi desenvolvido. Outra maneira de dizer isso é que favorece a "Convenção sobre a configuração". ou seja, as opções de configuração são muito limitadas, pois o software assume muitos dos aspectos de configuração. O software opinativo geralmente é mais rápido de dominar quando as suposições são entendidas.
Por outro lado, o software não-mencionado faz poucas suposições. E, como resultado, as estruturas de desenvolvimento de software / software que não são pioneiras costumam ter muitas opções de configuração. Um desenvolvedor normalmente precisa tomar muitas decisões em relação a vários aspectos do software. Muitas vezes, várias ferramentas são desenvolvidas para facilitar o tratamento dessas enormes opções. por exemplo, Visual Studio .NET para .NET, Eclipse IDE para Java, etc. O software não -OPONIONADO normalmente leva mais tempo para dominar do que o software opinativo.
tl; dr :
Muitas pessoas estão referenciando o ASP.NET MVC como uma estrutura "não-pioneira", e eu só queria refletir sobre isso.
É verdade que o ASP.NET MVC não exige muito; você pode usar qualquer solução de persistência que desejar, seja Linq-to-SQL, Entidades ADO.NET, NHibernate, etc.
Por outro lado, a estrutura MVC tende a favorecer a "convenção sobre a configuração", para citar Phil Haack, que sugere fortemente seguir o padrão predefinido para localizar controladores, visualizações, modelos e outros códigos. Embora você possa alterar esse comportamento, é mais fácil nadar com a corrente e, para a maioria das pessoas, não há problema em fazer isso.
Também cercam o ASP.NET MVC muitas pessoas opinativas, o que eu acho que leva a muitos tutoriais tendenciosos que insistem em abordar, por exemplo, testes de unidade e injeção de dependência; Sou a favor de bons testes e separação de preocupações, mas percebo que esses tópicos são levados pela garganta um pouco, muitas vezes antes de abordar conceitos básicos mais úteis.
Mais uma vez, tenho que admitir que, nessas áreas, a própria estrutura está completamente aberta para a adoção de qualquer solução de teste de unidade que você deseja, bem como de qualquer injeção de dependência e estruturas de zombaria que você deseja usar, então acho que isso fornece outro exemplo de flexibilidade, mesmo dentro do "bashing da bíblia" dos testes de unidade, etc. que parece estar acontecendo.
É a quantidade de convenções implementadas em uma estrutura e o número de decisões que foram tomadas.
Se, por exemplo, houver 5 (ou mais) maneiras diferentes de enviar dados de formulário para uma ação do controlador (que é o caso do ASP.NET MVC), a estrutura parecerá bastante "sem opinião" - a decisão será tomada para você!
Se, no entanto, a estrutura permitir (desabilitando diretamente outras formas ou incentivando-a fortemente) apenas uma maneira de fazer isso (como é o caso do Fubu MVC), você poderia dizer que a decisão foi tomada pela estrutura , tornando a estrutura opinativa.
O exemplo que você verá muito no momento é a estrutura do ASP.NET MVC. É incrivelmente extensível, mas essa é a sua queda em alguns aspectos, não há carne para isso. Deseja acessar os dados? Você terá que escrever isso sozinho. Quer algum AJAX acontecendo? Idem.
No entanto, como é altamente extensível, se você construir sobre ele, poderá transformá-lo em uma estrutura opinativa. É isso que os MVCContrib fazem, eles fornecem métodos específicos para fazer as coisas, o que significa que você precisa escrever menos código.
Isso significa que, se você quiser se afastar da opinião, geralmente há mais trabalho a fazer do que se estivesse trabalhando na versão vanilla. Este é um cenário 80/20. Se você escolheu sua estrutura opinativa corretamente, você só quer romper com as opiniões em 20% das vezes e será altamente produtivo nos outros 80% das vezes.