什么是自以为是的软件？
我经常看到有人说某些软件“非常有见地”，或者说微软倾向于写下“无知”的框架。 这实际上是什么意思？
如果一个框架是自以为是的话，它就会locking或引导你进入自己的行事方式。
例如：有些人认为模板系统不应该提供对用户定义的方法和函数的访问，因为它使系统保持打开状态返回原始的HTML。 所以一个自以为是的框架开发者只允许访问数据结构。 通过devise，软件正在限制和鼓励devise师按照自己的方式做事。
另一个例子（ 取自信号链接 ）是wiki的 。 维基的devise者有很多意见。 他们认为HTML对于人们来说太复杂了，所以他们想出了更自然的方式来更新内容。 他们也剥夺了花哨的devise，因为他们觉得重点应该更多的是内容而不是devise。
苹果在devise产品时有强烈的意见。
没有意见的软件devise更像PERL / PHP。 它允许开发人员和开发人员相信制定正确的决策，并将更多的控制权交给他们。
我也会把微软放在非专业的专栏里。 一个微软框架的一个很好的例子： .NET 。 通过打开CLR和规范，它将其打开为各种语言和实现方式。
意见软件意味着基本上有一种方法（ 正确的方法 ）来做事情，尝试做不同的事情将是困难和令人沮丧的。 另一方面，以正确的方式做事 ™可以使得使用软件开发变得非常容易，因为您必须减less决策的数量，并且软件devise人员专注于软件工作的能力也得到提高。 如果您的问题很好地映射到解决scheme，那么意见明确的软件可以很好地使用。 解决问题的那些不映射到提供的工具的部分可能是一个真正的痛苦。 这里的例子是Ruby on Rails。
另一方面，非观点化的软件为用户（开发者）留下了许多灵活性。 它不禁止解决问题的一种方法，而是提供可用于以多种方式解决问题的灵活工具。 这样做的缺点可能是因为工具非常灵活，所以开发任何解决scheme可能相对困难。 更多的解决scheme可能需要由用户（开发人员）手工编码，因为框架没有提供足够的帮助。 您还必须考虑如何提供解决scheme，平庸的开发人员最终可能会因为购买某些自以为是的软件而导致较差的解决scheme。 PERL很可能是非自由软件的典型例子。
我的理想是一个没有意见的框架，但有一个强有力的惯例。 我会把ASP.NET MVC的这个类别。 实际上所有的软件都有一定程度上的自我评估（虽然也许不是PERL）。 MVC在select模型方面有很强的约定，但是提供了许多不同的方法来解决这些约定中的问题。 有些方法甚至可能会破坏模型。 然而，正确使用，按照在这样的框架下开发的惯例可以是一个真正的喜悦。
它基本上是软件，它的作者认为它应该工作的方式，而不是试图取悦每个人。 这意味着很多人不会喜欢它，但那些做的人会喜欢它。
Rails可能是一个自以为是的框架的典型例子：你以他们的方式行事，一切都很顺利。 如果你不这样做，你会有些痛苦。 但是，没关系 – 如果你不想用自己的方式做事，你不想使用Rails。
为了平衡的缘故，我会提供一个更有利于自以为是的方法（相对于其他一些答案）的（相当自以为是的）描述。
意见框架提供了一个“黄金道路”，这是大多数人和大多数情况下最好的做法（在作者眼中）。
然而，这并不一定意味着locking。 这意味着它可能需要一些额外的努力来做不同的事情。
less一些自以为是的框架提供了一些不同的select，让你决定。
意见框架通常会消除开发人员的负担，重新发明轮子，或者一次又一次地重新思考同样的问题，从而帮助专注于眼前的实际问题。
在开放源代码世界中，您可以find许多自以为是的竞争框架，所以您仍然有一个select。 你只需要select自己的黄金道路。
意见软件的构build和devise方式使得以某种方式轻松完成任务。 它比其他人更喜欢某些devise模式。 在这个过程中，很难偏离它开发的软件开发风格。 另一种说法是它支持“公约重于configuration”。 即，configuration选项是非常有限的，因为软件承担了许多configuration方面。 一旦理解了这些假设，意见一般的软件通常会更快掌握。
另一方面，未经select的软件几乎没有任何假设。 因此，未经select的软件/软件开发框架通常倾向于具有许多configuration选项。 开发人员通常不得不就软件的各个方面做出很多决定。 通常，开发各种工具以使处理这些巨大的选项更容易。 例如用于.NET的Visual Studio .NET，用于Java的Eclipse IDE等等。未经授权的软件通常需要比自以为是的软件更长的时间才能掌握。
很多人都把ASP.NET MVC作为一个“非select性”的框架，我只是想在这方面考虑一些想法。
确实，ASP.NET MVC不要求太多; 你可以使用任何你喜欢的持久性解决scheme，无论是Linq-to-SQL，ADO.NET实体，NHibernate等等。
另一方面，MVC框架倾向于支持“约定优于configuration”，引用菲尔·哈克（Phil Haack）的观点，他强烈build议遵循预定义的模式来定位控制器，视图，模型和其他代码。 虽然你可以改变这种行为，但用目前的方式游泳更容易，对于大多数人来说，这样做没有任何问题。
同样围绕着ASP.NET MVC也是很多有见地的人，我发现它导致了很多有偏见的教程，比如unit testing和dependency injection; 我所有的testing和分离都是很好的，但是我确实认为这样的话题会让我们感到一丝不高，通常会在涵盖更多有用的基础知识之前。
还有，我不得不承认，在这些领域内，框架本身完全开放，可以采用任何你想要的unit testing解决scheme，以及你想要使用的任何dependency injection和嘲讽框架，所以我想这也是另一个例子。灵活性，甚至在unit testing的“圣经抨击”等内，似乎正在进行。
这是框架内实施的公约的数量和已经采取的决定的数量。
例如，如果有5种（或更多）不同的方法将表单数据提交给控制器动作（ASP.NET MVC中就是这种情况），那么框架似乎相当“非自负” – 决策已经结束给你！
但是，如果框架只能通过直接禁用其他方式，或者强烈鼓励它（或者通过强烈的鼓励）来实现这种function（就像Fubu MVC那样），那么你可以说这个决定已经被框架，从而使框架的意见。
您现在将看到很多的例子是ASP.NET MVC框架。 这是惊人的可扩展性，但这是在某些方面倒台，没有任何肉。 想要做数据访问？ 你必须自己写。 想要一些AJAX？ 同上。
然而，由于它具有高度的可扩展性，如果你在它的基础上，你可以把它变成一个自以为是的框架。 这是MVCContrib喜欢做的，他们给你具体的做事方法，这意味着你必须写更less的代码。
这确实意味着，如果你想打破这个观点，那么比起在香草版本上工作，往往还有更多的工作要做。 尽pipe如此，这是一个80/20的情况。 如果你正确地select了自己的框架，那么你只需要20％的时间来打破这个观点，而另外80％的时间你将会获得高产。
tl; dr ：
- 意见 ：例如Ruby on Rails 。 有一种特别喜欢的方式来做事情，并且以这种方式获得很多支持。 以其他方式做事情是困难的，或者对于一些制度是不可能的（卡桑德拉想到）。
- 毫不客气 ：例如Perl 5 。 你可以任何你喜欢的方式，任何你喜欢的方式，任何风格。 所有样式同样开放，有效和支持。
