Is it deemed bad practice to inject the DAO into the constructor? and if so, why?

I have a开发者_开发知识库 (DAL) Data Access Layer (but this question is relevant for DAOs as well) which is communicating with a restful web service in android (which is less relevant other than the fact that I am not wanting to include heavy restful libraries as the interaction isn't so complex).

I have a object which wraps a list which is populated by information from this data access layer, as the user scans down and reaches the bottom of this list, this object retrieves another set of information from the DAL.

I would like the calling class of this list wrapping object to only have to make calls to the the list wrapping object and not the DAL (or a DAO). I could then construct a single DAL and pass it to the constructors of these list wrapping objects, then the calling class can just keep making calls to this list wrapping object and that object can handle the retreival of new information.

So, does this sound like bad practice or just a really bad explanation?

Is it a bad idea to inject DALs and DAOs in the constructor of the domain object?

---

The answer depends on whether you feel strongly about "anemic domain models" and mixing object-oriented with functional programming.

One problem is that you'll create a cyclic dependency that way: model and persistence packages have to know about each other. If you use a more functional style, and don't give a DAO reference to a model object, then it's a one-way relationship.

I wouldn't like your design much. I fear that it's too coupled. I'm not bothered by mixing a functional style in.

---

Domain Objects are typically data carriers without any real logic. I would hence consider it bad design to tightly couple it with your DAO logic. The general logic might go something like:

public class DataService {
    private DAO dao;
}

public class UserService {
    private DataService svc;

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

---

You are introducing a circular dependency there, so it's not the best design.

If you are developing an android app, and you are scrolling a list, then SlowAdapter and EfficientAdapter are probably what you are looking for.

---

If I understood you correctly what you are implementing is pagination. And your solution for it is how I would (and have) implemented it myself.

Passing the DAL to the constructor is not bad per se. Best practise would be using a Dependency Injection framework (Spring is a prominent example) in-order to avoid "hard coded" dependencies between layers.

But since you mentioned Android I doubt that using such a framework is a good idea or even possible. (Maybe Android has some sort of DI build-in?)

To summarize you seem to have given some thought about your application architecture. I wouldn't worry about passing arguments to a constructor.