В продолжение темы предыдущего поста. Поскольку не всем понятно, в чем цимес этой технологии, постараюсь проиллюстрировать на условных примерах. ( Подробнее )
"Соответственно поле ссылки желательно переименовать" Вырывать руки и глаза всем. Никакой LINQ, кодогенерация и прочие технологии тут не помогут - проблема в консерватории.
Ну для начала тут все плохо :) 1) придурочный заказчик, меняющий требования через три недели после начала работы 2) придурочные бизнес-аналитики, которые не вырвали у него с кровью признание, что он не прав. 3) поля с одинаковыми именами без префиксов или алиасов таблиц - вырывать руки проектировщику БД и слоя доступа. 4) две "почти" идентичные таблицы в БД 5) код и маппинги мы рефакторингом поменяем, а для базы данных alter кто генерить будет? А если между разработкой и приходом психа заказчика обновление уже отдеплоено на тестовые базы данных многогигабайтных размеров?
Короче, ORM тут это решение 10% всех проблем с разработкой.
Ну, видимо, вы не работали в заказной разработке. На моей практике на одного нормального заказчика приходится два психа по типу "мы еще не знаем, что именно нам нужно, но это должно работать через три месяца". Некоторые были готовы за это платить неплохие деньги, и приходилось соглашаться. А иногда это еще бывает и новая бизнес-область, в которой нет опыта у аналитиков, и вообще приходится вешаться.
Про поля с одинаковыми именами вообще не понял. Т.е. если у вас есть куча таблиц, где есть ссылка на валюту, то поля ссылки у вас называются не CurrencyId, а каждое поле по своему? Типа Table1CurrencyId, Table2CurrencyId и т.п.? Как-то это похоже на нечитаемый ужас.
Насчет полной идентичности я не говорил. Просто у них было два одинаковых поля. Не вижу, в чем тут проблема.
Насчет alter-а - его писать руками, это пока неизбежно. Но здесь alter - меньшая из бед. Главное - поменять в сотне мест в коде.
Comments 4
Вырывать руки и глаза всем. Никакой LINQ, кодогенерация и прочие технологии тут не помогут - проблема в консерватории.
Reply
Reply
1) придурочный заказчик, меняющий требования через три недели после начала работы
2) придурочные бизнес-аналитики, которые не вырвали у него с кровью признание, что он не прав.
3) поля с одинаковыми именами без префиксов или алиасов таблиц - вырывать руки проектировщику БД и слоя доступа.
4) две "почти" идентичные таблицы в БД
5) код и маппинги мы рефакторингом поменяем, а для базы данных alter кто генерить будет? А если между разработкой и приходом психа заказчика обновление уже отдеплоено на тестовые базы данных многогигабайтных размеров?
Короче, ORM тут это решение 10% всех проблем с разработкой.
Reply
Про поля с одинаковыми именами вообще не понял. Т.е. если у вас есть куча таблиц, где есть ссылка на валюту, то поля ссылки у вас называются не CurrencyId, а каждое поле по своему? Типа Table1CurrencyId, Table2CurrencyId и т.п.? Как-то это похоже на нечитаемый ужас.
Насчет полной идентичности я не говорил. Просто у них было два одинаковых поля. Не вижу, в чем тут проблема.
Насчет alter-а - его писать руками, это пока неизбежно. Но здесь alter - меньшая из бед. Главное - поменять в сотне мест в коде.
Reply
Leave a comment