Считается ли плохой практикой вводить DAO в конструктор?и если да, то почему?

Question

У меня есть (DAL) уровень доступа к данным (но этот вопрос также актуален для DAO), который взаимодействует с успокоительным веб-сервисом в Android (который менее важен, за исключением того факта, что я не хочу включать тяжелые остальные библиотеки, так как взаимодействие не так сложно).

У меня есть объект, который упаковывает список, который заполняется информацией из этого уровня доступа к данным, поскольку пользователь просматривает и достигает нижней части этого списка, этот объект получает другой набор информации из DAL.

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

Итак, это звучит как плохая практика или просто очень плохое объяснение?

Является ли плохой идеей вставлять DAL и DAO в конструктор объекта домена?

Answer 1

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

Одна проблема заключается в том, что вы создадите циклическую зависимость таким образом: пакеты моделей и персистентности должны знать друг о друге. Если вы используете более функциональный стиль и не указываете DAO ссылку на объект модели, тогда это односторонняя связь.

Мне бы не очень понравился твой дизайн. Я боюсь, что это слишком тесно. Меня не беспокоит смешивание функционального стиля в.

Answer 2

Вы вводите там круговую зависимость, поэтому это не лучший дизайн.

Если вы разрабатываете приложение для Android и прокручиваете список, то SlowAdapter и EfficientAdapter , вероятно, то, что вы ищете.

Answer 3

Domain Objects обычно являются носителями данных без какой-либо реальной логики. Поэтому я бы посчитал плохим замыслом тесно связать его с вашей DAO логикой. Общая логика может выглядеть примерно так:

public class DataService {
    private DAO dao;
}

public class UserService {
    private DataService svc;

    public DomainObject createDomainObject() {
       return new DomainObject(dao.getData());
    } 
}

Answer 4

Если я правильно вас понял, то, что вы делаете, - это нумерация страниц.И ваше решение для этого состоит в том, как я (и сделал бы) реализовал это сам.

Передача DAL в конструктор сама по себе неплоха.Наилучшей практикой будет использование Dependency Injection фреймворка (яркий пример Spring), чтобы избежать «жестко запрограммированных» зависимостей между слоями.

Но так как вы упомянули Android, я сомневаюсь, что использованиетакая структура - хорошая идея или даже возможная.(Может быть, в Android есть какая-то встроенная DI-система?)

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