답변:
프레임 워크가 의견이 있다면, 그것들이 당신의 일을하는 방식으로 고정 시키거나 안내합니다.
예를 들어, 어떤 사람들은 템플릿 시스템이 시스템이 원시 HTML을 반환 할 수 있도록 개방 된 상태에서 사용자 정의 메소드 및 기능에 대한 액세스를 제공해서는 안된다고 생각합니다. 따라서 의견이 많은 프레임 워크 개발자는 데이터 구조에만 액세스 할 수 있습니다. 설계 상 소프트웨어는 제한적이며 디자이너가 자신의 방식대로 일하도록 장려합니다.
신호 링크에서 가져온 또 다른 예 는 wiki 입니다. 위키의 디자이너들은 많은 의견을 가지고있었습니다. 사람들이 HTML을 작성하기에는 너무 복잡하다고 생각했기 때문에 콘텐츠를보다 자연스럽게 업데이트 할 수 있다고 생각했습니다. 또한 디자인보다 컨텐츠에 더 중점을 두어야한다고 생각했기 때문에 멋진 디자인을 제거했습니다.
애플은 제품을 디자인 할 때 강한 의견을 가지고있다.
비 소집 소프트웨어 설계 는 PERL / PHP와 유사합니다. 이를 통해 개발자는 개발자가 올바른 결정을 내릴 수 있고 신뢰할 수있게됩니다.
또한 비 소위 열에 Microsoft를 배치 할 것입니다. opininated되지 않은 Microsoft 프레임 워크의 좋은 예 : .NET. CLR과 사양을 열어서 모든 종류의 언어와 구현 스타일을 열었습니다.
의견 수렴 된 소프트웨어는 기본적으로 일을하는 방법 ( 올바른 방법 ™)이 있으며 다르게 수행하려고하는 것은 어렵고 실망 스러울 수 있음을 의미합니다. 반면, 올바른 방식으로 작업을 수행 하면 의사 결정 횟수가 줄어들고 소프트웨어 설계자가 소프트웨어 작업에 집중할 수있는 능력이 향상되므로 소프트웨어로 개발하기가 매우 쉽습니다. 문제가 솔루션에 적절하게 매핑되면 잘 수행 된 경우 의견을 수렴 한 소프트웨어를 사용하는 것이 좋습니다. 제공된 도구에 매핑되지 않은 문제 부분을 해결하는 것은 정말 어려울 수 있습니다. 여기에 Ruby on Rails가 있습니다.
반면, 비 오피니언 화 소프트웨어는 사용자 (개발자)에게 많은 유연성을 제공합니다. 문제를 해결하는 한 가지 방법을 제시하지는 않지만 여러 가지 방법으로 문제를 해결하는 데 사용할 수있는 유연한 도구를 제공합니다. 이것의 단점은 도구가 매우 유연하기 때문에 솔루션을 개발하기가 상대적으로 어려울 수 있다는 것입니다. 프레임 워크가 충분한 도움을 제공하지 않기 때문에 더 많은 솔루션을 사용자 (개발자)가 직접 코딩해야 할 수도 있습니다. 또한 솔루션을 제공하는 방법에 대해 훨씬 더 많은 생각을해야하며 평범한 개발자는 일부 의견이있는 소프트웨어를 구입했을 때보 다 더 나쁜 솔루션을 얻게 될 수 있습니다. PERL은 아마도 비 소위 소프트웨어의 전형적인 예일 것입니다.
이상적으로는 비 피니언 화 프레임 워크이지만 강력한 규칙이 있습니다. 이 범주에 ASP.NET MVC를 넣을 것입니다. 실제로 모든 소프트웨어는 어느 정도 평가됩니다 (아마도 PERL은 아님). MVC는 모델 선택에 강력한 규칙을 가지고 있지만 이러한 규칙 내에서 문제를 해결하는 다양한 방법을 제공합니다. 이러한 방법 중 일부는 모델을 손상시킬 수도 있습니다. 그러나 그러한 틀에서 개발 된 관례에 따라 올바르게 사용하는 것은 진정한 기쁨이 될 수 있습니다.
기본적으로 모든 사람을 기쁘게하지 않고 저자가 생각하는 방식으로 작동하는 소프트웨어입니다. 그것은 많은 사람들이 그것을 좋아하지 않지만 그것을하는 사람들은 그것을 좋아한다는 것을 의미합니다.
Rails는 아마도 의견이 수렴 된 프레임 워크의 정식 사례 일 것입니다. 그렇지 않으면 약간의 고통이 있습니다. 그러나 괜찮습니다. 일을하고 싶지 않다면 Rails를 사용하고 싶지 않습니다.
균형을 위해서 나는 (다른 의견 들과는 대조적으로) 의견있는 접근법에 더 유리한 (아주 의견없는) 설명을 제공 할 것이다.
의견을 수렴 한 프레임 워크는 "골든 경로"를 제공하며, 이는 대부분의 사람들과 대부분의 시나리오 (저자 눈에)에 대한 모범 사례로 간주됩니다.
그러나 이것이 반드시 잠금을 의미하는 것은 아닙니다. 그것은 다르게 일을하기 위해 약간의 노력이 필요할 수 있음을 의미합니다.
덜 의견이 많은 프레임 워크는 다양한 옵션을 제공하며 결정을 내릴 수 있습니다.
의견을 수렴 한 프레임 워크는 일반적으로 개발자가 휠을 재발 명하거나 동일한 문제를 반복해서 다시 생각해야하는 부담을 제거하여 실제 문제에 집중할 수 있도록 도와줍니다.
오픈 소스 세계에서는 많은 의견을 가지고 있지만 경쟁하는 프레임 워크를 찾을 수 있으므로 여전히 선택할 수 있습니다. 당신은 당신의 자신의 황금 경로를 선택해야합니다.
의견 수렴 된 소프트웨어는 특정 방식으로 작업을 쉽게 수행 할 수있는 방식으로 구축 및 설계되었습니다. 특정 디자인 패턴을 다른 패턴보다 선호합니다. 이 과정에서 개발 된 소프트웨어 개발 스타일에서 벗어나기가 어려워집니다. 그것을 넣는 또 다른 방법은 "구성에 대한 컨벤션"을 선호한다는 것입니다. 즉, 소프트웨어가 많은 구성 측면을 가정하므로 구성 옵션은 매우 제한적입니다. 가정이 이해되면 의견이 수렴 된 소프트웨어는 일반적으로 더 빠르게 마스터 할 수 있습니다.
반면에 미지의 소프트웨어는 거의 가정하지 않습니다. 결과적으로, 비 피니언 화되는 소프트웨어 / 소프트웨어 개발 프레임 워크는 종종 많은 구성 옵션을 갖는 경향이 있습니다. 개발자는 일반적으로 소프트웨어의 다양한 측면에 대해 많은 결정을 내려야합니다. 종종 이러한 다양한 옵션을보다 쉽게 처리 할 수 있도록 다양한 도구가 개발되었습니다. 예를 들어 Visual Studio .NET for .NET, Eclipse IDE for Java 등. 일반적으로 의견이없는 소프트웨어는 의견이없는 소프트웨어보다 마스터하는 데 시간이 더 걸립니다.
tl; dr :
많은 사람들이 ASP.NET MVC를 "비노 피니언 화"프레임 워크로 언급하고 있으며, 그에 대한 몇 가지 생각으로 무게를 달고 싶었습니다.
ASP.NET MVC가 너무 많은 권한을 요구하지 않는 것은 사실입니다. Linq-to-SQL, ADO.NET Entities, NHibernate 등 원하는 지속성 솔루션을 사용할 수 있습니다.
반대로 MVC 프레임 워크는 Phil Haack을 인용하기 위해 "컨벤션에 대한 컨벤션"을 선호하는 경향이 있습니다. Phil Haack은 컨트롤러, 뷰, 모델 및 기타 코드를 찾기 위해 사전 정의 된 패턴을 따르는 것이 좋습니다. 이 동작을 변경할 수는 있지만 현재와 함께 수영하는 것이 더 쉽고 대부분의 사람들에게는 아무런 문제가 없습니다.
또한 ASP.NET MVC를 둘러싼 많은 사람들이 의견을 모았습니다. 이는 단위 테스트 및 의존성 주입과 같이 다루어야 할 많은 편견 튜토리얼로 이어집니다. 나는 좋은 테스트와 관심사 분리를 위해 노력하고 있지만, 그러한 주제가 목구멍에 약간 눌려 있고 종종 더 유용한 기본 사항을 다루는 것으로 인식합니다.
다시 말하지만, 그 영역 내에서 프레임 워크 자체는 원하는 단위 테스트 솔루션뿐만 아니라 사용하려는 종속성 주입 및 모의 프레임 워크를 채택 할 수 있도록 완전히 개방되어 있음을 인정해야합니다. 단위 테스트 등의 "성서 강타"내에서도 유연성이 있습니다.
그것은 프레임 워크에서 구현 된 규약의 양과 결정의 수입니다.
예를 들어 양식 데이터를 컨트롤러 작업 (ASP.NET MVC의 경우)에 제출하는 5 가지 이상의 방법이 있다면 프레임 워크가 "비 소위"인 것 같습니다. 당신에게!
그러나 프레임 워크가 다른 방법을 직접 사용하지 않도록 설정하거나 강력하게 권장하여 해당 방법을 수행하는 한 가지 방법 (Fubu MVC의 경우) 만 가능하면 프레임 워크에서 결정을 내렸다고 말할 수 있습니다. 따라서 프레임 워크에 대한 의견을 제시합니다.
현재 많이 볼 수있는 예는 ASP.NET MVC 프레임 워크입니다. 그것은 놀랍게도 확장 가능하지만 어떤면에서 쇠약합니다. 고기가 없습니다. 데이터 액세스를 원하십니까? 직접 작성해야합니다. AJAX를 원하십니까? 같게.
그러나 확장 성이 뛰어 나기 때문에 그것을 기반으로하면 의견이 많은 프레임 워크로 바꿀 수 있습니다. 이것은 MVCContrib 와 비슷한 기능을 수행하므로 코드를 적게 작성 해야하는 특정 작업 방법을 제공합니다.
이것은 의견에서 벗어나고 싶다면 바닐라 버전을 사용하는 것보다 더 많은 작업이 필요하다는 것을 의미합니다. 이것은 80/20 시나리오입니다. 당신이 당신의 의견 프레임 워크를 올바르게 선택했다면 당신은 단지 시간의 20 %의 의견에서 벗어나고 싶을 것이고 당신은 다른 시간의 80 %에서 생산성이 높아질 것입니다.