Знаток - активирует дочерний профиль на основе свойства
Бизнес-логика должна инкапсулироваться в одном месте. Мы можем гарантировать, что логика всегда выполняется и последовательно выполняется. Используя классы, которые, должно пробежать все действие, включающее объект на базе данных, мы можем гарантировать, что вся проверка выполняется правильно. Существует одно место для этого кода, и любой разработчик на проекте может легко открыть этот класс и видеть логику (потому что документация может и действительно становиться устаревшей, код является единственной надежной формой документации).
Это трудно сделать с хранимыми процедурами. У Вас может быть больше чем один контакт sproc с той же таблицей (таблицами). Объединение в цепочку нескольких sprocs вместе так, чтобы логика находилась только в одном, становится громоздким. Это - забастовка один. Как Вы определяете, "Что все бизнес-правила окружают объект X" в базе данных? Весело проведите время ища тысячи sprocs, пытающиеся разыскать это.
Номер два - то, что Вы связываете свою бизнес-логику с Вашим механизмом персистентности. Вы не можете хранить все свои данные в той же базе данных, или некоторые могут находиться в XML и т.д. Этот тип несоответствия является трудным на разработчике.
Проверку трудно выполнить, если логика находится только в базе данных. Вы действительно называете sproc для проверки каждого поля на форме ввода данных? Правила проверки и бизнес-логика являются близкими родственниками. Эта логика должна все быть выполнена в том же месте!
2 ответа
Профиль может быть активирован только свойствами, переданными из командной строки. Это связано с тем, что свойства в POM могут быть обработаны только после того, как POM проанализирован, и в этот момент уже слишком поздно разрешать активацию профиля.
Вы находитесь в некоторой ловушке-22 с этим подходом, если вы не могут передать свойство из командной строки, указать активацию профиля в файле settings.xml (как правило, это не лучшая идея) или использовать обходной путь в моем предыдущем ответе , чтобы использовать наличие файла маркера.
Последняя альтернатива, если вы используете Maven 2.1.0+, - это деактивировать профиль через командную строку только для родительского POM, это все еще явно не идеально.
Вы можете деактивировать. профиль с символом "!" или '-' вот так:
mvn install -P !profile-1,!profile-2
Чтобы напрямую ответить на мой собственный вопрос: в многомодульной сборке все свойства устанавливаются до запуска сборки, поэтому невозможно активировать / деактивировать профиль в одном из модулей во время сборки, основанной на установке свойства в дочернем POM. Однако, если вы ищете способ сделать это другими способами, пожалуйста, прочтите этот комментарий