回答:
フレームワークが独断である場合、それはあなたをロックして、物事の彼らのやり方にあなたを導きます。
たとえば、テンプレートシステムでは、システムが未加工のHTMLを返すことができるようになっているため、ユーザー定義のメソッドや関数へのアクセスを提供すべきではないと考える人もいます。したがって、独断的なフレームワーク開発者は、データ構造へのアクセスのみを許可します。設計上、ソフトウェアは制限的であり、設計者が自分のやり方で物事を行うことを奨励しています。
別の例（信号リンクから取得）はwikiの例です。ウィキの設計者は多くの意見を持っていました。HTMLは複雑すぎて記述できないと考えたため、コンテンツを更新するためのより自然な方法であると感じた方法を思いつきました。彼らはまた、デザインよりもコンテンツに重点を置くべきだと感じたため、派手なデザインを取り除いた。
アップルは自社の製品を設計する際に強い意見を持っています。
意見のないソフトウェア設計は、PERL / PHPに似ています。これにより、開発者は信頼して開発者が正しい決定を下し、より多くの制御を手に入れることができます。
私はまた、マイクロソフトを非意見の列に入れました。意見が出されていないMicrosoftフレームワークの良い例：.NET。CLRと仕様を開くことにより、あらゆる種類の言語と実装のスタイルに開放されました。
意見のソフトウェアは、物事を行うための基本的に1つの方法（正しい方法 ™）があり、それを別の方法で行うことは困難でイライラすることを意味します。一方、正しい方法を実行することで、ソフトウェアの開発を非常に簡単にすることができます。これは、行う必要のある決定の数が減り、ソフトウェア設計者がソフトウェアの動作に集中する能力が高まるためです。問題がソリューションにうまく対応していれば、意見が分かれたソフトウェアはうまく使えばうまくいくでしょう。提供されているツールにマッピングされていない問題の部分を解決するのは、本当に大変なことです。ここでの例は、Ruby on Railsです。
一方、意見のないソフトウェアは、ユーザー（開発者）に多くの柔軟性を与えます。問題を解決する1つの方法を規定していませんが、さまざまな方法で問題を解決するために使用できる柔軟なツールを提供しています。これの欠点は、ツールが非常に柔軟であるため、ソリューションを開発することが比較的難しい場合があることです。フレームワークでは十分なヘルプが提供されないため、ソリューションの多くはユーザー（開発者）が手動でコーディングする必要がある場合があります。また、解決策を提供する方法についてより多くのことを考える必要があり、平凡な開発者は、彼らがいくつかの独断的なソフトウェアを購入した場合よりも貧弱な解決策になってしまう可能性があります。PERLは、おそらく意見のないソフトウェアの典型的な例です。
私の理想は意見を持たないフレームワークですが、強い慣習を持っているものです。私はこのカテゴリにASP.NET MVCを入れます。実際には、すべてのソフトウェアがある程度独断されています（おそらくPERLではありません）。MVCのモデルの選択には強力な規則がありますが、それらの規則内の問題を解決するためのさまざまな方法が提供されています。それらの方法のいくつかは、モデルを壊すことさえあります。ただし、このようなフレームワークで開発された規則に従って正しく使用することは、本当に楽しいことです。
それは基本的にソフトウェアであり、作者がそれを機能させるべきだと考えている方法で機能します。それは多くの人がそれを好きではないということを意味しますが、そうする人はそれを愛するでしょう。
Railsはおそらく見解の定まったフレームワークの標準的な例でしょう。あなたは自分たちのやり方で物事を行い、すべてがスムーズです。そうでなければ、あなたはいくらかの苦痛を味わっています。しかし、それは問題ありません。自分のやり方でやりたくない場合は、Railsを使用したくありません。
バランスのために、私は（他のいくつかの回答とは対照的に）意欲的なアプローチに有利な（むしろ意欲的な）説明を提供します。
意見の分かれたフレームワークは、「ゴールデンパス」を提供します。これは、ほとんどの人とほとんどのシナリオ（著者の目には）のベストプラクティスであると考えられています。
ただし、これは必ずしもロックインを意味するものではありません。つまり、物事を別の方法で実行するには、追加の作業が必要になる場合があります。
あまり考えられていないフレームワークは多くの異なるオプションを提供し、それはあなたが決めることを任せます。
意見の分かれたフレームワークは、通常、開発者の負担を取り除いて車輪を作り直したり、同じ問題を何度も考え直したりすることで、当面の本当の問題に集中できるようにします。
オープンソースの世界では、多くの独断的でありながら競合するフレームワークを見つけることができるため、選択肢はまだあります。あなた自身の黄金の道を選ぶ必要があるだけです。
意見のソフトウェアは、特定の方法で物事を簡単に実行できるように構築および設計されています。他よりも特定のデザインパターンを優先します。その過程で、それが開発されたソフトウェア開発のスタイルから逸脱することが難しくなります。別の言い方をすれば、「構成よりも規約」が優先されるということです。つまり、ソフトウェアは多くの構成側面を想定しているため、構成オプションは非常に制限されています。想定されたソフトウェアは、仮定が理解されれば、通常は習得するのがより速くなります。
一方、意見のないソフトウェアは、ほとんど想定していません。その結果、ピノピネーションされていないソフトウェア/ソフトウェア開発フレームワークには、多くの構成オプションが含まれる傾向があります。開発者は通常、ソフトウェアのさまざまな側面に関して多くの決定を行わなければなりません。多くの場合、これらの膨大なオプションを簡単に扱えるように、さまざまなツールが開発されています。例：Visual Studio .NET for .NET、Eclipse IDE for Javaなど。通常、意見のないソフトウェアは、意見のあるソフトウェアよりも習得に時間がかかります。
多くの人々がASP.NET MVCを「ピノピネーションされていない」フレームワークと呼んでいますが、私はそれについていくつか考えてみました。
ASP.NET MVCがあまり義務付けていないのは事実です。Linq-to-SQL、ADO.NET Entities、NHibernateなど、好きな永続化ソリューションを使用できます。
反対に、MVCフレームワークは、「構成よりも規約」を支持する傾向があります。PhilHaackは、コントローラー、ビュー、モデル、およびその他のコードを見つけるための事前定義されたパターンに従うことを強く示唆しています。この動作を変更することはできますが、電流で泳ぐ方が簡単であり、ほとんどの人にとって、それを行うことには問題はありません。
また、ASP.NET MVCを取り巻くのは、多くの独断的な人々であり、それらは、たとえばユニットテストや依存関係の注入など、カバーすることを主張する多くの偏ったチュートリアルにつながると私は思います。私はすべて、十分なテストと懸念の分離を望んでいますが、そのようなトピックは、しばしばより有用な基本をカバーする前に、少しずつ押し込まれていると思います。
繰り返しになりますが、これらの領域では、フレームワーク自体が、必要なユニットテストソリューションの採用や、使用したい依存性注入およびモックフレームワークの採用に完全にオープンであることを認めなければなりません。進行中のように見えるユニットテストなどの「聖書のバッシング」の範囲内でも、柔軟性。
フレームワークに実装されている規則の量と、行われた決定の数です。
たとえば、フォームデータをコントローラーアクションに送信する方法が5つ（またはそれ以上）ある場合（ASP.NET MVCの場合）、フレームワークはかなり「意見が分かれている」ようです。あなたへ！
ただし、フレームワークが（他の方法を直接無効にするか、強く推奨することによって）そのことを実行する1つの方法のみを有効にする場合（Fubu MVCの場合）、決定はフレームワークによって行われたと言えます、したがって、フレームワークを説得力のあるものにします。
現時点でよく目にする例はASP.NET MVCフレームワークです。それは驚くほど拡張可能ですが、それはいくつかの点でその没落であり、それに肉はありません。データアクセスをしたいですか？自分で書く必要があります。AJAXを継続したいですか？同上。
ただし、拡張性が高いため、それを基に構築すれば、独自のフレームワークに変えることができます。これはMVCContribのようなものです。彼らはあなたがより少ないコードを書かなければならないことを意味する物事を行う特定の方法を提供します。
これは、あなたが意見から脱却したい場合、バニラ版で作業している場合よりも多くの作業が必要になることを意味します。これは80/20シナリオです。自分の意見に基づくフレームワークを正しく選択した場合は、意見の20％だけを破棄したいだけで、残りの80％は生産性が高くなります。