Что “кодирует условно”?

В контексте Grails «кодирование по соглашению» означает, что большой объем (утомительного и повторяющегося) явного кода и / или конфигурации заменяется простыми соглашениями об именах и структуре каталогов. Например:

• Любой класс, имя которого заканчивается на Controller в каталоге grails-app / controllers, автоматически является контроллером Spring, и определенные в нем закрытия будут привязаны к URL-адресам - вам не нужно настраивать это в файле XML как вам придется это сделать при использовании чистого Spring.
• То же самое и с taglibs (каталог grails-app / taglib) - больше никаких утомительных файлов TLD!
• Классы домена в grails-app / domain, вероятно, обладают самой "магией соглашений" ", который автоматически сопоставляется с автоматически созданной схемой БД - при этом имена таблиц и столбцов БД по соглашению идентичны именам свойств домена. Идея о том, что у вас есть определенные соглашения о размещении или именовании предметов, поэтому вам не нужно явно указывать программе, где находится материал или как он называется.
  Например, в ASP.Net MVC существует соглашение о том, где хранятся представления и как они называются. Это означает, что когда ваш код инструктирует сервер вернуть представление, среда выполнения будет искать представление с определенной структурой именования в определенных папках. См. Стр. 20 в этом pdf для большей ясности.

  Другой пример - соглашения об именах для методов. Например, на языке, управляемом событиями, у вас может быть выбор явно объявить, какой метод какие события обрабатывает, или вы можете полагаться на соглашение об именах, например ..._ OnOpen или ... OnClick, а затем полагаться на среду выполнения, чтобы выяснить правильный метод вызова данного события.

См. Соглашение о конфигурации . Это концепция разработки инструмента или инфраструктуры, в которой по умолчанию используются наиболее распространенные параметры конфигурации, поэтому для подавляющего большинства пользователей настройка не требуется.

Здесь много соглашений:

1. Как назвать элементы HTML, чтобы они были легко доступны в качестве параметров из HTTP-запроса;
2. Как связать атрибуты объекта с именами таблиц и столбцов в база данных;
3. Как распределить проект по каталогам / пакетам;

Это то, что вы делаете, когда обнаруживаете, что решаете общую проблему в определенном стиле. Вы замечаете сходство и систематизируете их в некую схему автоматизации.

Это означает, что если вы будете придерживаться определенных соглашений о кодировании, определенных в любой используемой вами структуре, основанной на соглашениях, вы получите множество функций бесплатно. Другими словами, если вы структурируете свое приложение в соответствии с ожиданиями среды, можно сэкономить много работы.

Было бы неплохо изучить преимущества и недостатки кодирования по соглашению.

In the context of Grails, "coding by convention" means that a lot of (tedious and repetitive) explicit code and/or configuration is replaced by simple naming and directory structure conventions. For example:

• Any class whose name ends with Controller in the grails-app/controllers directory is automatically a Spring controller and closures defined in it will be bound to URLs - you don't have to configure this in an XML file as you would have to when using pure Spring.
• The same goes for taglibs (grails-app/taglib directory) - no more tedious TLD files!
• Domain classes in grails-app/domain probably have the most "convention magic", being automatically mapped to an automatically generated DB schema - with DB table and column names being by convention identical to the domain property names.