Я часто вижу людей, которые говорят, что определенное программное обеспечение «очень самоуверенное» или что Microsoft имеет тенденцию писать «непродуманные» структуры. Что это на самом деле означает?
Ответы:
Если фреймворк самоуверенный, он блокирует или ведет вас к их действиям.
Например: некоторые люди считают, что система шаблонов не должна предоставлять доступ к пользовательским методам и функциям, так как она оставляет систему открытой для возврата необработанного HTML. Так что самоуверенный разработчик фреймворка разрешает доступ только к структурам данных. По замыслу, программное обеспечение ограничивает и побуждает дизайнера делать все по-своему.
Другой пример ( взят из ссылки сигналов ) - это пример вики . У дизайнеров вики было много мнений. Они думали, что HTML слишком сложен для людей, чтобы писать, поэтому они придумали то, что, по их мнению, является более естественным способом обновления контента. Они также лишили его модного дизайна, потому что считали, что внимание должно быть сосредоточено не на дизайне, а на содержании.
У Apple сильные мнения при разработке своих продуктов.
Непродуманный программный дизайн больше похож на PERL / PHP. Это позволяет разработчику и доверяет разработчику принимать правильные решения и дает больше контроля в их руках.
Я бы также поместил Microsoft в колонку без мнений. Хороший пример структуры Microsoft , которая является не-opininated: .NET. Открыв CLR и спецификации, он открыл его для всех видов языков и стилей реализации.
Мнение программного обеспечения означает, что в принципе есть один способ ( правильный путь ) делать что-то, и попытка сделать это по-другому будет трудной и разочаровывающей. С другой стороны, правильная работа ™ может очень облегчить разработку с программным обеспечением, поскольку количество решений, которые вам необходимо принять, уменьшается, а способность разработчиков программного обеспечения сконцентрироваться на работе программного обеспечения увеличивается. Мнение программного обеспечения может быть полезно для использования, если все сделано правильно, если ваша проблема хорошо отображается в решении. Решить те части вашей проблемы, которые не отображаются на предоставляемые инструменты, может быть реальной болью. Примером здесь может быть Ruby on Rails.
С другой стороны, неуверенное программное обеспечение оставляет большую гибкость пользователю (разработчику). Он не запрещает один метод решения проблемы, но предоставляет гибкие инструменты, которые можно использовать для решения проблемы разными способами. Недостатком этого может быть то, что, поскольку инструменты настолько гибки, может быть относительно сложно разработать какое-либо решение. Гораздо большее количество решений, возможно, придется кодировать вручную пользователю (разработчику), потому что фреймворк не предоставляет достаточной помощи. Вам также нужно больше думать о том, как предоставить решение, и посредственные разработчики могут в итоге получить более плохие решения, чем если бы они купили себе какое-то самоуверенное программное обеспечение. PERL, вероятно, является классическим примером неуверенного программного обеспечения.
Мой идеал - это неучтенная основа, но с сильными соглашениями. Я бы поставил ASP.NET MVC в эту категорию. На самом деле все программное обеспечение в некоторой степени является самоуверенным (хотя, возможно, не PERL). MVC имеет строгие соглашения в выборе модели, но предлагает множество различных способов решения проблем в рамках этих соглашений. Некоторые из этих способов могут даже сломать модель. При правильном использовании, однако, в соответствии с конвенциями, разработка в таких рамках может быть настоящей радостью.
Это в основном программное обеспечение, которое работает так, как его авторы считают, что оно должно работать, а не пытаться угодить всем. Это означает, что многим это не понравится, но тем, кто это сделает, понравится.
Rails, вероятно, является каноническим примером самоуверенного фреймворка: вы делаете все по-своему, и все гладко. Если вы этого не сделаете, вам будет больно. Но это нормально - если вы не хотите делать вещи по-своему, вы не хотите использовать Rails.
В целях баланса я приведу (довольно самоуверенное) описание, более благоприятное для самоуверенного подхода (в отличие от некоторых других ответов).
Мнения рамок обеспечивают «золотой путь», который, как предполагается, является наилучшей практикой для большинства людей и большинства сценариев (в глазах авторов).
Это, однако, не обязательно означает блокировку. Это означает, что может потребоваться дополнительное усилие, чтобы действовать по-другому.
Менее самоуверенные фреймворки предоставляют целый ряд различных вариантов и оставляют вам решать.
Множество фреймворков обычно снимает с разработчика бремя изобретать велосипед или переосмысливать ту же проблему снова и снова и, таким образом, помогают сосредоточиться на реальной проблеме.
В мире открытого исходного кода вы можете найти много самоуверенных, но конкурирующих фреймворков, так что у вас все еще есть выбор. Вам просто нужно выбрать свой золотой путь.
Мнение программного обеспечения построено и разработано таким образом, что позволяет легко делать вещи определенным образом. Это одобряет определенные образцы дизайна больше чем другие. В этом процессе это затрудняет отклонение от стиля разработки программного обеспечения, для которого оно было разработано. Еще один способ выразить это в том, что он одобряет «Конвенцию вместо конфигурации». Т.е. параметры конфигурации очень ограничены, так как программное обеспечение предполагает многие аспекты конфигурации. Мнение программного обеспечения обычно быстрее освоить, как только предположения понятны.
С другой стороны, незакрытое программное обеспечение делает несколько предположений. И, как результат, структуры программного обеспечения / разработки программного обеспечения, которые не были открыты, часто имеют множество вариантов конфигурации. Разработчик, как правило, должен принимать множество решений относительно различных аспектов программного обеспечения. Часто разрабатываются различные инструменты, чтобы облегчить работу с этими огромными возможностями. например, Visual Studio .NET для .NET, Eclipse IDE для Java и т. д. Для работы с незарегистрированным программным обеспечением обычно требуется больше времени, чем с программным обеспечением.
тл; др :
Многие люди ссылаются на ASP.NET MVC как на «незавершенную» структуру, и я просто хотел взвесить пару мыслей по этому поводу.
Это правда, что ASP.NET MVC не требует слишком много; Вы можете использовать любое решение по сохранению, которое вам нравится, будь то Linq-to-SQL, ADO.NET Entities, NHibernate и т. д.
С другой стороны, инфраструктура MVC имеет тенденцию отдавать предпочтение «соглашению над конфигурацией», цитирует Фила Хаака, который настоятельно рекомендует следовать заранее определенному шаблону для размещения контроллеров, представлений, моделей и другого кода. Хотя вы можете изменить это поведение, легче плыть по течению, и для большинства людей это не проблема.
В ASP.NET MVC также окружает много мнительных людей, которые, как я считаю, ведут ко многим предвзятым учебникам, которые настаивают на освещении, например, модульное тестирование и внедрение зависимостей; Я все за хорошее тестирование и разделение проблем, но я чувствую, что такие темы немного запутываются, часто опережая более полезные основы.
Опять же, я должен признать, что в этих областях сама структура полностью открыта для принятия любого решения по модульному тестированию, которое вы хотите, а также любых структур внедрения зависимостей и mocking, которые вы хотите использовать, поэтому я предполагаю, что это еще один пример гибкость, даже в рамках "библейского избиения" модульного тестирования и т. д., которое, похоже, продолжается.
Это количество соглашений, реализованных в рамке, и количество принятых решений.
Если, например, существует 5 (или более) различных способов отправки данных формы в действие контроллера (что имеет место в ASP.NET MVC), инфраструктура выглядит довольно «неубедительно» - решение принято тебе!
Однако, если инфраструктура позволяет (либо путем прямого отключения других способов, либо путем решительного поощрения) только один способ сделать это (как в случае с Fubu MVC), вы можете сказать, что решение было принято платформой Таким образом, делая рамки самоуверенными.
Примером, который вы увидите много на данный момент, является ASP.NET MVC framework. Он удивительно расширяемый, но это его падение в некоторых отношениях, в нем нет мяса. Хотите сделать доступ к данным? Вам придется написать это самостоятельно. Хотите немного AJAX? То же самое.
Однако, поскольку он очень расширяемый, если вы опираетесь на него, вы можете превратить его в самоуверенную структуру. Это то, что делают подобные MVCContrib , они дают вам конкретные методы выполнения действий, что означает, что вы должны писать меньше кода.
Это означает, что если вы хотите оторваться от мнения, часто есть над чем работать, чем если бы вы работали над ванильной версией. Это сценарий 80/20, хотя. Если вы выбрали правильную концептуальную основу правильно, вы захотите отказаться от мнений только в 20% случаев, а остальные 80% времени вы будете очень продуктивными.