Уровень доступа к данным или наличие объекта с методами CRUD?

Question

Раньше у меня был Уровень доступа к данным, который принимает объект по параметру и обрабатывает с абстракцией требуемый тип персистентности. На моей новой работе архитектор планирует внедрить операцию CRUD (load..save..delete..update) во все объекты модели. Эти методы будут иметь объект за параметром, который будет обрабатывать сохранение объекта. Пример: загрузка (постоянство IPersistence). У меня есть некоторые сомнения по поводу расширяемости и того, что каждый объект модели должен реализовывать все методы загрузки, сохранения, удаления, обновления.

Каков наилучший подход?

Answer 1

DAL полностью.

Вы хотите иметь возможность изолировать свои транзакции, чтобы объекты не знали об их постоянстве. В противном случае код может привести к неосуществимому кошмару, когда объекты могут активировать циклические обходы базы данных, и трудно объединить несколько транзакций в одно атомарное действие.

Я выяснил это трудным путем. :)

Answer 2

Полагаю, это вечный вопрос, и у обоих подходов есть свои плюсы и минусы и множество последователей, которые клянутся ими.

Подход repository, который вы предпочитаете (имея репозиторий / шлюз, как вы его называете) для обработки операций CRUD, делает ваши реальные бизнес-классы меньше и экономнее, поскольку они, вероятно, содержат только данные и, возможно, валидацию / бизнес-правила ,

В этом случае вы выполняете операции CRUD один раз, но, скорее всего, один раз для каждого типа объекта, с которым вы имеете дело.

С другой стороны, подход smart business object может утверждать, что операции CRUD для данного объекта в любом случае специфичны для этого объекта, поэтому код для выбора, обновления, удаления такого объекта всегда будет специфичным, поэтому может также проживать внутри самого объекта.

В этом случае вы реализуете операции CRUD для каждого класса объектов один раз - я не вижу большого недостатка по сравнению с подходом к хранилищу в этом случае, на самом деле.

Я лично сегодня склоняюсь к подходу к хранилищу, но я также вижу преимущества в подходе «умный бизнес-объект» - оба они верны, и я думаю, вам просто придется либо убедить нового архитектора в своей позиции, или договориться с другим подходом.

Марк

Answer 3

Я думаю, что в обоих случаях реализация не должна быть повторяющейся , а реализована только один раз и наследоваться (например) при необходимости.
Подклассы и их методы понадобятся только для нестандартных заданий (например, пользовательских запросов с их пользовательскими параметрами).

---

Теперь этот вопрос сводится к философской дискуссии POJO . Позвольте мне попытаться сформулировать это своими словами ;-):

1. , учитывая, что модель специфична для каждой конкретной проблемы и, следовательно, для каждого приложения
2. учитывая, что для модели требуется много аспектов : постоянство является одним из аспектов, необходимых для модели, наряду с проверкой, документацией, компонентами и сообщениями пользовательского интерфейса, предложениями пользователя, миграцией между версиями. .
3. учитывая, что одна модель достаточно сложна для понимания, поддержки и так далее, без объединения всех аспектов
4. вы делаете вывод, что любой аспект должен быть выведен из объектов модели.

На самом деле, мы только выводим на экран сложные вещи (как правило, требующие некоторого кодирования) и сохраняем очень простые вещи Pojo (обычно объявления, часто с использованием аннотаций).

---

Другим огромным преимуществом , не имеющим технического суперкласса для модели , является то, что модель может использоваться как собственный "объект передачи данных" для переноса этой информации между системами:

1. между слоями
2. между JVM (через сериализацию), например, между машинами

Если бы в наших модельных классах были бы технические суперклассы, они не были бы полезны в таких различных контекстах. Например:

1. Сопротивление на объекте модели часто можно использовать только в некотором слое (в архитектурных решениях). Например, только бизнес-уровень будет иметь доступ к уровню данных для сохранения.
2. Во время переноса данных с одного компьютера на другой каждый компьютер может работать со своей собственной базой данных. Таким образом, объекты модели могут свободно передаваться, если они не несут указатели на базу данных; каждый сервер должен использовать свою собственную базу данных. Для того же объекта модели возможны вариации в других аспектах , что облегчается, если аспекты не переносятся одним и тем же объектом.