Мне кажется, что вы действительно хотите что-то мягко набранное с минимальным количеством кода, так как требования меняются слишком быстро. Вот как я делаю проект, в котором я использую PHP для бэкенда. Я использую sql и json для быстрого извлечения данных из базы данных и их возврата клиенту.
Обычно я делаю выборку в базе данных, для каждой строки результата я конвертирую строку в карту, где каждый столбец становится ключом со значением в качестве результата для этого столбца. Этот список карт затем преобразуется в json с помощью общей процедуры json, и json отправляется с сервера.
Такая установка чрезвычайно проста для передачи некоторых данных с сервера на клиент, но:
- Вы теряете безопасность типов, которую вы можете получить, используя hibernate / xml / remoting.
- Ваши клиенты тесно связаны со схемой вашей базы данных.
- Несмотря на то, что быстро захватывать и переносить данные - это зло.
- Если вы измените запрос, чтобы получить больше данных, перекомпиляция клиентов не требуется, если им не нужно использовать новые данные.
Чтобы дать вам представление о том, как это выглядит в PHP, я делаю:
В моем объекте доступа к данным:
function getAllPortal() {
$sql = "select firstname, lastname, U.* from person, portal_user U where id=person order by firstname, lastname";
$prep = $this->db->prepare($sql);
return $prep->execute();
}
И в моем http сервисном (основанном на отдыхе) коде:
$accPerson = new AccountPerson($db);
echo json_encode($accPerson->getAllPortal());
Чтобы сделать это в Java, вам, вероятно, потребуется создать некоторую среду для вывода данных в список карт (или другую простую структуру, которую вы хотите передать клиентам). Я сделал один в PHP, который делает это, что также позволяет использовать подготовленные операторы.
Некоторые другие соображения , которые вы могли бы рассмотреть (даже если вы делаете не так, как указано выше), могут быть:
Избегайте слоев. Иметь их как можно меньше. Если вы используете Hibernate - примите это. Используйте объекты непосредственно в своих запросах, конвертируйте их в json и отправляйте. Слои делают ваш код устойчивым, если вашим данным понадобится несколько человек (или клиентов) - из-за этого ваш код не хочет быстро меняться. Знать, когда делать слои, а когда нет, - хитрость и сопротивляться ей так долго, как только можете. Написание слоев занимает время.
В качестве транспорта используйте XML или, что еще лучше, JSON. Не выбирайте схему, которая сопротивляется изменениям, таким как xml и / или сериализации в pojos. Pojos отлично подходит для бизнес-логики, но отстой для передачи данных. Если ваш клиент достаточно тонкий, не беспокойтесь о десериализации вашего json снова в объекты. Используйте JSON напрямую. Опять-таки, как и в случае со слоями, хитрость заключается в том, чтобы знать, когда воссоздание pojos дает ценность для бизнеса, а когда нет. Как и в случае со слоями, не поддавайтесь этой работе, пока не увидите ценность. Написание / обслуживание десериализаторов занимает время.