Для меня это все о разделении интересов.Каждый объект должен иметь одну и только одну ответственность.Таким образом, ваши модели предназначены для представления каждой таблицы в базе данных.В вашем примере будет Monkey POJO, который представляет обезьяну таблицы в вашей базе данных.Допустим, вы пишете все свои SQL-запросы в своих POJO, в течение первых нескольких месяцев все в порядке, затем ваша команда решает, что им нужно перейти на другого поставщика БД, который не полностью поддерживает ваш синтаксис SQL, и что теперь?По сути, вы женились на своем коде у продавца БД.Кроме того, код, который работает с базами данных, обычно плотный, длинный и повторяющийся.
Более того, передавая извлечение данных на другой уровень, вы также можете получить «db», который не может быть db, скажем несколько csvфайлы для (плохого) примера, но вы понимаете, ваш дизайн более гибок.Для разработчика база данных - это источник данных, с которым он / она взаимодействует через общий стабильный interface, не требуя при этом тонкостей этой базы данных.
Еще одна вещь, есть четыре общих операции, которые выобычно это делается в базе данных, это Create, Read, Delete, Update (CRUD), поэтому, помещая всю логику базы данных на свой собственный уровень, вы можете написать меньше кода в двух местах:
- Данныеслой: так как у вас есть повторяющиеся операции CRUD
- Ваши POJO - это простые простые данные с установщиками / получателями
PS: Возможно, самое большое преимущество от разбиения этих двух слоев, приложения и данных, эточто вы можете использовать такие инструменты, как ORM для автоматической генерации всего вашего уровня доступа к данным, тогда вы сосредоточены только на разработке приложения и можете с большей легкостью менять, изменять или изменять свою базу данных.