Лекция
Привет, Вы узнаете о том , что такое соглашение по конфигурации, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое соглашение по конфигурации, кодирование по соглашению, convention over configuration , настоятельно рекомендую прочитать все из категории Проектирование веб сайта или программного обеспечения.
соглашение по конфигурации (также известное как кодирование по соглашению , Convention over configuration ) - это парадигма проектирования программного обеспечения, используемая программными средами, которая пытается уменьшить количество решений, которые разработчик, использующий структуру, должен принимать, не обязательно теряя гибкость. Эта концепция была введена Дэвидом Хайнемайером Ханссоном для описания философии веб-фреймворка Ruby on Rails , но связана с более ранними идеями, такими как концепция «разумных значений по умолчанию » и принцип наименьшего удивления в дизайне пользовательского интерфейса .
По сути, эта фраза означает, что разработчику нужно только указать нетрадиционные аспекты приложения. Например, если в модели есть класс « Продажи», соответствующая таблица в базе данных по умолчанию называется «продажи». Только если кто-то отклоняется от этого соглашения, такого как таблица «продажи продукта», нужно писать код для этих имен.
Когда соглашение, реализованное инструментом, соответствует желаемому поведению, оно ведет себя так, как ожидалось, без необходимости записывать файлы конфигурации. Только когда желаемое поведение отклоняется от реализованного соглашения, требуется явная конфигурация.
Использование этой фразы в Ruby on Rails особенно сосредоточено на его файле проекта по умолчанию и структуре каталогов, что избавляет разработчиков от необходимости писать файлы конфигурации XML, чтобы указать, какие модули должен загружать фреймворк, что было распространено во многих более ранних фреймворках.
Недостатки подхода к соглашению по сравнению с подходом к конфигурации могут возникать из-за конфликтов с другими принципами проектирования программного обеспечения, такими как дзен Python «явное лучше, чем неявное». Рамки программного обеспечения на основе конвенции по конфигурации часто включает в себя язык домен специфичного с ограниченным набором конструкций или инверсией управления , в которой разработчик может воздействовать только на поведение , используя ограниченный набор крючков , оба из которых может сделать реализующее поведение не легко выражаться в предоставленных соглашениях труднее, чем при использовании программной библиотеки , которая не пытается уменьшить количество решений, которые разработчики должны принимать или требовать инверсии управления.
Другие методы уменьшения количества решений, которые необходимо принять разработчику, включают идиомы программирования и библиотеки конфигурации с многоуровневой архитектурой .
Используя этот подход, разработчикам нужно только настроить специфичные для приложения и нестандартные аспекты приложения. Об этом говорит сайт https://intellect.icu . Другие аспекты, такие как подключение входных элементов через специализированные модели к таблицам базы данных, могут быть обеспечены соглашениями, такими как одинаковое именование классов и таблиц, и их нужно настраивать только в том случае, если соглашения отклоняются. Например, если в соглашении указано, что класс модели должен называться в единственном числе, а соответствующая таблица базы данных - во множественном числе, разработчику не нужно делать какую-либо явную конфигурацию для программы с классом модели, чтобы использовать Saleэту таблицу sales. Но если таблица что-то называется products_sold, он должен это настроить.
Некоторым фреймворкам требуется несколько файлов конфигурации, каждый со множеством настроек. Они предоставляют информацию, специфичную для каждого проекта, от URL-адресов до сопоставлений между классами и таблицами базы данных. Многие файлы конфигурации с множеством параметров часто трудно поддерживать.
Например, ранние версии Java-средства отображения сохраняемости Hibernate отображали сущности и их поля в базу данных, описывая эти отношения в файлах XML. Большая часть этой информации могла быть раскрыта путем обычного сопоставления имен классов с одноименными таблицами базы данных и полей с их столбцами, соответственно. Более поздние версии отказались от файла конфигурации XML и вместо этого использовали эти самые соглашения, отклонения от которых можно указать с помощью аннотаций Java (см. Спецификацию JavaBeans, ссылку ниже).
Многим традиционным фреймворкам требуется несколько файлов конфигурации для настройки параметров конкретного проекта. Эти параметры влияют не только на глобальные значения, но и на повторяющиеся значения для многих элементов приложения, например, на назначение классов таблицам базы данных. С увеличением размера и сложности приложения размер и сложность этих файлов конфигурации также увеличивались, что, в свою очередь, уменьшало ремонтопригодность приложения. Использование аннотаций вместо файлов конфигурации не устраняет эту проблему, а просто устраняет ее.
Соглашение перед настройкой точно сокращает эти часто структурно повторяющиеся записи в файлах конфигурации и аннотациях. Это означает, что разработчикам нужно только изучить соглашения, лежащие в основе фреймворка, и им не придется иметь дело с огромным количеством конфигураций. Это увеличивает ремонтопригодность приложения и, таким образом, снижает общие затраты на разработку и обслуживание программного обеспечени
Многие современные фреймворки используют подход, основанный на соглашении, а не на конфигурации .
Однако эта концепция старше, восходит к концепции по умолчанию и может быть обнаружена совсем недавно в корнях библиотек Java . Например, спецификация JavaBeans сильно зависит от этого. Процитируем спецификацию JavaBeans 1.01
«Как правило, мы не хотим изобретать огромный класс java.beans.everything, от которого люди должны наследовать. Вместо этого мы хотели бы, чтобы среда выполнения JavaBeans обеспечивала поведение по умолчанию для« нормальных »объектов, но позволяла объектам переопределить заданную часть поведения по умолчанию, унаследовав от определенного интерфейса java.beans.something. "
Рисунок-2 Соглашение о конфигурации в действии
Рис.1 Структура папок проекта Visual Studio MVC
Сравнение веб-фреймворков
PSR (PHP Standards Recommendations)
Java specification requests
JSCS: JavaScript Code Style, Google JavaScript Style Guide
Python Enhancement Proposal
паттерны программирования
принципы программирования
антипатерны программирования
SQL Style Guide Database standards
Исследование, описанное в статье про соглашение по конфигурации, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое соглашение по конфигурации, кодирование по соглашению, convention over configuration и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Проектирование веб сайта или программного обеспечения
Из статьи мы узнали кратко, но содержательно про соглашение по конфигурации
Комментарии
Оставить комментарий
Проектирование веб сайта или программного обеспечения
Термины: Проектирование веб сайта или программного обеспечения