Comments 6
UFO just landed and posted this here
На мой взгляд, таким суждением вы совершаете главную ошибку: пытаетесь абстрагироваться от реляционной базы данных на уровне некоего объектного представления (реализуемого через интерфейс DIB).
Существующие проблемы, связанные с разработкой ORM-решений и их использования в основном кроются в отсутствии реального мэппинга объектов на отношения. Каждая СУБД имеет свои ограничения и свои фичи, которые необходимо учитывать и использовать в конкретных проектах. СУБД также накладывает и некоторые ограничения, которые после разработки некоего мока (IDB) потребуют переписать половину системы. Другими словами, вести разработку изначально нужно с учетом этих ограничений, а также преимуществ конкретной СУБД.
Второй момент заключается в том, что моки они годятся только для юнит-тестов, реальная база данных позволяет по-другому взглянуть на функциональность приложения, больше проверить и исправить ошибок на ранних стадиях разработки.
Используйте объектную СУБД, но сразу, и проблема разработки снизу вверх отпадает сама собой.
Конечно, разработать бОльшую часть базы данных до момента кодирования функционала освобождает от массы проблем связанных с развитием структуры данных и соответствующей модификации самих данных (что несомненно возникает при разработке снизу вверх). Однако, давно известны процессные паттерны для обслуживания этой задачи (Фаулер. «Рефакторинг баз данных»).
Я пробовал оба подхода при разработке решений с использованием базы данных: разработка сверху вниз и снизу вверх. В целом у каждого подхода есть минусы, но то что программный код неразрывно связан с логикой (запросами), реализуемой на стороне СУБД, обязывает аккуратно и внимательно относится к мэппингу при разработке.
Существующие проблемы, связанные с разработкой ORM-решений и их использования в основном кроются в отсутствии реального мэппинга объектов на отношения. Каждая СУБД имеет свои ограничения и свои фичи, которые необходимо учитывать и использовать в конкретных проектах. СУБД также накладывает и некоторые ограничения, которые после разработки некоего мока (IDB) потребуют переписать половину системы. Другими словами, вести разработку изначально нужно с учетом этих ограничений, а также преимуществ конкретной СУБД.
Второй момент заключается в том, что моки они годятся только для юнит-тестов, реальная база данных позволяет по-другому взглянуть на функциональность приложения, больше проверить и исправить ошибок на ранних стадиях разработки.
Используйте объектную СУБД, но сразу, и проблема разработки снизу вверх отпадает сама собой.
Конечно, разработать бОльшую часть базы данных до момента кодирования функционала освобождает от массы проблем связанных с развитием структуры данных и соответствующей модификации самих данных (что несомненно возникает при разработке снизу вверх). Однако, давно известны процессные паттерны для обслуживания этой задачи (Фаулер. «Рефакторинг баз данных»).
Я пробовал оба подхода при разработке решений с использованием базы данных: разработка сверху вниз и снизу вверх. В целом у каждого подхода есть минусы, но то что программный код неразрывно связан с логикой (запросами), реализуемой на стороне СУБД, обязывает аккуратно и внимательно относится к мэппингу при разработке.
Спасибо за ценные замечания.
Я не написал это в заметке, но абстракция IDB будет уточняться и эволюционировать, как только будет возникать дополнительная информация, например, выбор NHibernate как ORM спровоцирует замену типа список кортежей в GetAuthor на список объектов класса, например, Author. Таким образом процесс разработки учитывает ограничения СУБД, просто в начальный момент, код к которому приведен в заметке, СУБД еще не выбрана и ограничений пока нет, поэтому используется максимально абстрактная реализация, по мере возникновения ограничений эта абстрактная реализация будет заменема более конкретной.
В общем случае, например в CRUD, подход, который я описал будет более сложным и не даст хорошей отдачи; но в проекте, над которой я сейчас работаю, он оказался успешным так, как база исользовалась только для хранения информации и быстрому поиску по ней, а почти вся логика работы приложения заключалась в обработке данных до занесения их в базу.
Я не написал это в заметке, но абстракция IDB будет уточняться и эволюционировать, как только будет возникать дополнительная информация, например, выбор NHibernate как ORM спровоцирует замену типа список кортежей в GetAuthor на список объектов класса, например, Author. Таким образом процесс разработки учитывает ограничения СУБД, просто в начальный момент, код к которому приведен в заметке, СУБД еще не выбрана и ограничений пока нет, поэтому используется максимально абстрактная реализация, по мере возникновения ограничений эта абстрактная реализация будет заменема более конкретной.
В общем случае, например в CRUD, подход, который я описал будет более сложным и не даст хорошей отдачи; но в проекте, над которой я сейчас работаю, он оказался успешным так, как база исользовалась только для хранения информации и быстрому поиску по ней, а почти вся логика работы приложения заключалась в обработке данных до занесения их в базу.
Sign up to leave a comment.
Разработка снизу-вверх и базы данных.