Уровень доступа к данным или имеющий объект с методами CRUD?
tar xzf file.tar.gz
буквы:
- x - извлечение
- z - gunzip вход
- f - Чтение из файла, не stdin
3 ответа
Думаю, это вечный вопрос, и у обоих подходов есть свои плюсы и минусы, а также множество последователей, которые их поддерживают.
Подход репозиторий , который вы, кажется, предпочитаете (наличие репозитория / шлюза) как бы вы это ни называли) для обработки операций CRUD делает ваши фактические бизнес-классы меньше и компактнее, поскольку они, вероятно, содержат только данные и, возможно, правила проверки / бизнес-правила.
В этом случае вы реализуете операции CRUD один раз - но, скорее всего, один раз для каждого типа объекта, с которым вы имеете дело.
С другой стороны, подход интеллектуальный бизнес-объект может возразить, что операция CRUD над данной сущностью в любом случае специфична для этой сущности, поэтому код для выбора, обновления, удаления такой сущности всегда будет конкретным, поэтому он может также находиться внутри самого объекта.
DAL полностью.
Вы хотите иметь возможность изолировать свои транзакции, чтобы объекты не знали об их сохранении. В противном случае код может превратиться в непреодолимый кошмар, когда объекты могут активировать круговые обходы базы данных, и трудно свести несколько транзакций в одно атомарное действие.
Я понял это на собственном горьком опыте. :)
Я думаю, что в обоих случаях реализация не должна быть повторяющейся , а реализовываться только один раз и наследоваться (например) по мере необходимости.
Подклассы и их методы потребуются только для нестандартных заданий (например, пользовательских запросов с их пользовательскими параметрами).
Теперь вопрос сводится к философским дебатам POJO . Позвольте мне попытаться сформулировать это своими словами ;-):
- учитывая, что модель специфична для каждой конкретной проблемы и, следовательно, каждое приложение
- , учитывая, что многие аспекты требуются для модель : стойкость - это один из аспектов, требуемых для модели, наряду с проверкой, документацией, компонентами пользовательского интерфейса и сообщениями, предложениями пользователей, миграцией между версиями ...
- учитывая, что только модель является достаточно сложно , чтобы понять, поддерживать и так далее, без объединения всех аспектов
- вы делаете вывод, что любой аспект должен быть экстернализован из объектов модели.
Фактически, мы экстернализируем только сложные вещи (обычно требующие некоторого кодирования) и продолжаем очень простые вещи Pojo (обычно объявления, часто использующие аннотации).
Еще одно огромное преимущество , не имеющего технического суперкласса для модели , состоит в том, что модель может использоваться как собственный "объект передачи данных" «для передачи этой информации между системами:
- между уровнями
- между JVM (через сериализацию), например, между машинами
Если бы наши классы моделей имели технические суперклассы, они не были бы полезны в таких различных контекстах. Например:
- Устойчивость к объекту модели часто используется только на некотором уровне (в выборе архитектуры). Например, только бизнес-уровень будет иметь доступ к уровню данных для сохранения.
- Во время миграции данных с одной машины на другую каждая машина может работать со своей собственной базой данных. Таким образом, объекты модели могут свободно перемещаться, если они не содержат указателей на базу данных; каждый сервер должен использовать свою собственную базу данных. Для одного и того же объекта модели возможны вариации по другим аспектам , что упрощается, если аспекты не переносятся одним и тем же объектом.