Я часто бачу людей, які говорять про те, що певне програмне забезпечення "дуже впевнено" або що 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 і т.д.
tl; dr :
Дуже багато людей посилаються на ASP.NET MVC як на "неприхильний" фреймворк, і я просто хотів зважитися на пару думок з цього приводу.
Це правда, що ASP.NET MVC не надто мандат; Ви можете використовувати будь-яке стійке рішення, яке вам подобається, будь то Linq-to-SQL, ADO.NET Entities, NHibernate тощо.
З іншого боку, рамки MVC, як правило, надають перевагу "умові щодо конфігурації", щоб процитувати Філа Хаака, який наполегливо пропонує дотримуватися заздалегідь визначеної схеми розміщення контролерів, поглядів, моделей та іншого коду. Хоча ви можете змінити таку поведінку, плавати струмом простіше, і для більшості людей це робити не має жодної проблеми.
Також навколо ASP.NET MVC є багато впевнених у собі людей, що, як я вважаю, призводить до безлічі упереджених навчальних посібників, які наполягають на висвітленні, наприклад, тестування блоку та введення залежності; Я все для хорошого тестування та розділення проблем, але я вважаю, що такі теми трохи засунуті в горло, часто випереджаючи корисніші основи.
Знову ж таки, я маю визнати, що в цих областях сама структура повністю відкрита для прийняття будь-якого рішення для тестування одиниць, яке ви хочете, а також будь-які рамки введення залежностей та глузування, які ви хочете використовувати, тому я гадаю, що це є ще одним прикладом гнучкість, навіть у межах "библейського базування" одиничного тестування тощо, що, здається, триває.
Це кількість конвенцій, реалізованих у рамці, та кількість прийнятих рішень.
Якщо, наприклад, існує 5 (або більше) різних способів подати дані форми на дію контролера (що трапляється в ASP.NET MVC), рамка виглядає досить «невпевнено» - рішення прийняте тобі!
Якщо, однак, рамки дозволяють (або безпосередньо відключивши інші способи, або сильно заохочуючи її) лише один спосіб зробити цю річ (що стосується MVC Fubu), можна сказати, що рішення було прийняте рамкою , тим самим зробивши рамки надуманими.
Приклад, який ви багато побачите на даний момент, - це структура ASP.NET MVC. Це дивовижно розширюється, але в чомусь це його падіння, м'яса в ньому немає. Хочете зробити доступ до даних? Вам доведеться написати це самостійно. Хочете, щоб AJAX тривав? Дітто.
Однак, як це дуже розширюється, якщо ви будуєте на ньому, ви можете перетворити його на переконливі рамки. Це те, що подобається MVCContrib , вони дають вам конкретні методи виконання дій, а це означає, що вам потрібно писати менше коду.
Це означає, що якщо ви хочете відійти від думки, часто потрібно зробити більше роботи, ніж якби ви працювали над ванільною версією. Це, однак, сценарій 80/20. Якщо ви правильно вибрали свою висловлювану структуру, ви хочете лише відірватися від думок 20% часу, а інші 80% часу ви будете високопродуктивними.