Андрій Степанюк

Правильно в данном случае именно seeds.rb а не миграция, причём не только для тестирования.
Только его грамотно написать нужно, чтобы не вставлял уже существующие значения. Тогда rake db:seed можно будет вызывать в любой момент времени без всяких опасений.

По поводу исключений подробно описано в Exceptional Ruby. Несмотря на то что опубликовано в начале 2011, всё ещё актуально.

Use exceptions only for exceptional situations.

Invalid user input isn't unusual

При обработке неверного запроса от HTTP клиента нужно вернуть ответ HTTP .
REST response code for invalid data
Любые ответы HTTP 40x говорят о том, что HTTP клиент работает неправильно.

В случае работы в Ruby on Rails исключения считаются, видимо, нормальной практикой и поэтому от них никуда не уйти.
Trying to get a POST to return 400 bad request

При обработке POST запросов следует выдать пользователю сообщение о том где ошибка ("Выберите компании из списка"). Если ошибка в логике JS, то надо исправлять код JS.

DataMapper это не только гем, но шаблон проектирования, который часто противопоставляется шаблону ActiveRecord (см. труды Фаулера). Вне rails сообщества эти названия известны именно в таком контексте.
Однако.
Во первых гем DataMapper, не самая лучшая реализация шаблона DataMapper, уходящая куда-то вкось. Во вторых он просто уже не разрабатывается.
Гем ActiveRecord, напротив, едва ли не эталон всеобщей продуманности в мелочах и конечно (как иначе), ActiveRecord разрабатывается активно.

Присоединяясь к ответу Роман Крылов, скажу что лучший способ реализовать DataMapper в рельсах - построить его вокруг Sequel, прекрасной библиотеки доступа к БД, лишенной многих недостатков ActiveRecord связанных с его врожденной негибкостью (convention over configuration, ага) и проблем с производительностью (подгружает иногда что-то лишнее, редко, но в особых случая это может быть важно).

Когда использовать одно, а когда другое?
Если у вас есть возможность проектировать базу данных в соответствии с конвенциями Rails - однозначно используйте ActiveRecord. Вы сэкономите много сил и средств.
Если вы строите проект над готовой базой или если структура проектируемой БД слишком сложна - используйте Sequel, делайте преобразователи данных, стройте абстрактную, отвязанную от БД объектную модель.

Расскажу что знаю.

DataMapper уже не разрабатывается, разработчики этой библиотеки переименовали DM в ROM сейчас активно пилят его https://github.com/rom-rb
Пруф - https://twitter.com/datamapper/status/342595504909...

Так что для себя лично я решил не использовать DataMapper в проектах, хоть библиотека мне очень нравится в сравнении ActiveRecords, так как более понятно как это работает, можно просто описать модели без написания миграций и DM построит таблицы.

К ActiveRecords есть у меня какая-то необъяснимая неприязнь. Может потому, что я не использую Rails, а пишу на Sinatra.

Использую Sequel (sequel.jeremyevans.net). Долго сомневался мигрировать на него с DM, но как перешёл ни капли не пожалел - ЭТО ВОЛШЕБНО! Супер библиотека с кучей плагинов и возможностями, особенно при использовании PostgreSQL. Кстати, разработчики ROM решили при использовании SQL хранилица тоже использовать Sequel.

Вот видео доклад по Sequel на русском языке - www.youtube.com/watch?v=95TflPVKSI0

Клиент понимает только цифры, ему плевать на качество кода ровно до той поры, пока поддержка кода не станет ему в копеечку лишнюю. Приведите ему реальные доводы ЗА рефакторинг выражающиеся профитом в денежном эквиваленте и вуаля. Ну а если этих доводов нет - только личное мироощущение, то нужен ли рефакторинг?

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