Соглашения о присвоении имен для миграций направляющих
Если и Иглой и Стогом сена являются ДАО, то опции 1 и 2 вне рассмотрения.
причина этого состоит в том, что ДАО должны только быть ответственны за содержание свойств объектов реального мира, которые они моделируют, и только имеют методы получателя и методы установщика (или просто прямой доступ свойства). Это делает сериализацию ДАО в файл, или создание методов для дженерика выдерживает сравнение / универсальная копия, легче записать, поскольку код не содержал бы целый набор "если" операторы для пропуска этих вспомогательных методов.
Это просто оставляет опцию 3, которая большинство согласилось бы быть корректным поведением.
Опция 3 имеет несколько преимуществ с самым большим преимуществом, являющимся поблочным тестированием. Это вызвано тем, что и объекты Иглы и Стога сена могут легко копироваться теперь, тогда как, если бы опция 1 или 2 использовалась, внутреннее состояние или Иглы или Стога сена должно было бы быть изменено, прежде чем поиск мог быть выполнен.
, Во-вторых, с искателем теперь в отдельном классе, весь поисковый код может быть сохранен в одном месте, включая общий поисковый код. Принимая во внимание, что, если бы поисковый код был помещен в ДАО, общий поисковый код был бы или сохранен в сложной иерархии классов, или с классом Помощника Искателя так или иначе.
3 ответа
I agree with the previous poster. The naming should focus on readability. But also keep in mind that you can't (nor should) have two migrations with the same name.
So, general names like edit_foo_model is generally not a good idea (since, what happens when you want to add more columns to that model), then it would be better to group the columns into what the purpose is, like update_foo_for_bar_support. You can usually skip adding model since, well, everyone knows that migrations do handle models, so there is no need to mention that in the name (that is, update_foo instead of update_foo_model).
Also, what I usually do is to keep different changes separated. So, if there are multiple different changes in a model, I'd separate them into different migration files, one for adding columns and one for removing columns for instance.
Я бы разделил несколько изменений схемы на несколько миграций! Тогда вы можете легко назвать отдельные миграции!
The point is readability- to find out fast what the migration is responsible for.. if you write too much "data" in the name, it makes it harder to scan and you shoot yourself in the foot.
So.. if it's 1-2 changes, write it in the name, if there are too many changes, write update_foo_model (or edit_foo_model)