Информация об изменениях

Сообщение Re: Дизайн слоя доступа к данным от 27.02.2019 12:25

Изменено 27.02.2019 12:50 L_G

Re: Дизайн слоя доступа к данным
scf,
не ответ "за какой вариант", но мысли на тему:

если речь о БД, в которых традиционно записи имеют ключевое поле (ID) —
играет роль момент и место генерации этого ID для новых записей.

в варианте (а) скорее всего метод "create" должен возвращать сгенеренный на стороне сервера ID,
а метод "update" — принимать его как параметр.

в варианте (b) метод "save" скорее всего будет требовать ID как параметр,
то есть либо он должен генерироваться на клиенте (что часто чревато проблемами),
либо интерфейсу нужен дополнительный метод "get_new_id" — т.е. все равно одним "save" не обойтись.

P.S.: метод "save", добавляющий записи при ID==null и т.п. будет не идемпотентным
Re: Дизайн слоя доступа к данным
scf,
не ответ "за какой вариант", но мысли на тему:

если речь о БД, в которых традиционно записи имеют ключевое поле (ID) —
играет роль момент и место генерации этого ID для новых записей.

в варианте (а) скорее всего метод "create" будет присваивать объекту сгенеренный на стороне сервера ID
и не должен срабатывать вообще, если ID объекту уже присвоен,
а метод "update", наоборот, не должен срабатывать при ID==null.

в варианте (b) метод "save" должен либо требовать ID!=null,
(т.е. интерфейсу нужен дополнительный метод "get_new_id" и одним "save" не обойтись),
либо он 1) будет не идемпотентным, при этом еще 2) генерация ID без участия сервера чревата проблемой неуникальных ID.