#java #android #data-access-layer #dao
#java #Android #уровень доступа к данным #dao
Вопрос:
У меня есть уровень доступа к данным (DAL) (но этот вопрос также актуален для DAO), который взаимодействует с веб-сервисом restful в Android (что менее актуально, кроме того факта, что я не хочу включать тяжелые библиотеки restful, поскольку взаимодействие не такое сложное).
У меня есть объект, который оборачивает список, который заполняется информацией с этого уровня доступа к данным, когда пользователь просматривает вниз и достигает нижней части этого списка, этот объект извлекает другой набор информации из DAL.
Я бы хотел, чтобы вызывающий класс этого объекта переноса списка должен был вызывать только объект переноса списка, а не DAL (или DAO). Затем я мог бы создать один DAL и передать его конструкторам этих объектов переноса списка, тогда вызывающий класс может просто продолжать вызывать этот объект переноса списка, и этот объект может обрабатывать восстановление новой информации.
Итак, это звучит как плохая практика или просто очень плохое объяснение?
Плохая ли идея вводить DAL и DAO в конструктор объекта домена?
Комментарии:
1. Если вопрос специфичен для Android, имеет ли смысл поместить его в качестве тега?
2. Хотел, чтобы это был более общий вопрос, но, оглядываясь назад, фактор Android кажется более актуальным, чем я изначально думал. Я добавил тег.
Ответ №1:
Ответ зависит от того, сильно ли вы относитесь к «анемичным моделям предметной области» и смешиванию объектно-ориентированного с функциональным программированием.
Одна из проблем заключается в том, что таким образом вы создадите циклическую зависимость: пакеты model и persistence должны знать друг о друге. Если вы используете более функциональный стиль и не даете ссылку DAO на объект модели, то это односторонняя связь.
Мне бы не очень понравился ваш дизайн. Я боюсь, что это слишком связано. Меня не беспокоит смешивание функционального стиля.
Комментарии:
1. Если уровню доступа к данным не было поручено фактически создавать объекты домена, а просто предоставлять соответствующую информацию (в данном случае строку json) для создаваемых объектов списка, тогда я удаляю циклическую зависимость (хотя я понимаю, что это уже не DAL / DAO, а просто адаптер). Как вы это видите?
2. Дополнительное усложнение без какой-либо выгоды, которую я вижу.
Ответ №2:
Domain Objects обычно это носители данных без какой-либо реальной логики. Поэтому я бы счел это плохим дизайном, чтобы тесно связать его с вашей DAO логикой. Общая логика может выглядеть примерно так:
public class DataService {
private DAO dao;
}
public class UserService {
private DataService svc;
public DomainObject createDomainObject() {
return new DomainObject(dao.getData());
}
}
Комментарии:
1. Это утверждение —
Domain Objects are typically data carriers without any real logic, немного неверно. Объекты домена должны иметь бизнес-логику и быть частью расширенной модели предметной области, в отличие от DTO, которые предназначены для передачи данных (и встречаются в анемичных моделях предметной области).
Ответ №3:
Вы вводите там циклическую зависимость, так что это не лучший дизайн.
Если вы разрабатываете приложение для Android и просматриваете список, то SlowAdapter и EfficientAdapter, вероятно, являются тем, что вы ищете.
Комментарии:
1. Если уровню доступа к данным не было поручено фактически создавать объекты домена, а просто предоставлять соответствующую информацию (в данном случае строку json) для создаваемых объектов списка, тогда я удаляю циклическую зависимость (хотя я понимаю, что это уже не DAL / DAO, а просто адаптер). Как вы это видите?
Ответ №4:
Если я правильно вас понял, то, что вы реализуете, — это разбивка на страницы. И ваше решение для этого заключается в том, как я бы (и реализовал) его сам.
Передача DAL конструктору сама по себе неплоха. Наилучшей практикой было бы использование инфраструктуры внедрения зависимостей (Spring является ярким примером), чтобы избежать «жестко закодированных» зависимостей между слоями.
Но поскольку вы упомянули Android, я сомневаюсь, что использование такой платформы является хорошей идеей или даже возможно. (Может быть, в Android есть какая-то встроенная функция DI?)
Подводя итог, вы, похоже, немного подумали об архитектуре вашего приложения. Я бы не стал беспокоиться о передаче аргументов конструктору.