6

Suppose I have a DAO which touches the DB.

Should the DAO return only data and then it's up to me to do the instantiation or is the DAO supposed to also do the instantiation and return me the instance - and why should I choose one method over another?

// Example with instantiation
studentDAO = {
  getById: function() {
    const data = db.query('SELECT FROM `students`...');

    return new Student(data);
  }
}

// Example without instantiation (just returns the data)
studentDAO = {
  getById: function() {
    const data = db.query('SELECT FROM `students`...');

    return data;
  }
}
Improve this question

2 Answers 2

Reset to default
8

You should return the instance, because the purpose of the dao is to hide the database implementation from the rest of the code and your data object is specific to your db.

In fact you should even avoid passing data into a constructor as in your example.

eg.

studentDAO = 
{
    getById: function() 
    { 
        const data = db.query('SELECT FROM `students`...');

        var s = new Student();
        s.Id = data[0]: 
        //that data can be accessed like this and that element 0 
        //contains the student Id is information specific to the 
        //database and the responsibility of the DAO class NOT the 
        //Student class

        return s;
    } 
}
Improve this answer
10
  • 1
    Thanks - Why should I avoid passing data to the constructor?
    – nicholaswmin
    Jul 13, 2017 at 6:41
  • because then your constructor, which is not part of the dao needs to know about the data type and structure. this should be kept inside the dao
    – Ewan
    Jul 13, 2017 at 6:42
  • 2
    done, excuse smart phone editor
    – Ewan
    Jul 13, 2017 at 6:50
  • 2
    Avoiding proper constructors is not a best practice! In this example, a new Student(data[0]) would be no more coupled than var s = new Student(); s.Id = data[0], but the latter is more likely to contain bugs, e.g. if new fields are added to the Student that must also be initialized. But except for this very unusual design, the main point of the answer is spot on: to be a proper abstraction, the DAL has to operate on domain objects like Student.
    – amon
    Jul 13, 2017 at 8:16
  • 1
    @NicholasKyriakides - most database libraries aren't gonna return, say, some string when you call db.query. It's probably gonna be some kind of cursor pointing at rows. You don't want to pass those to Student's constructor, but rather extract the meaningful data from there (eg, the student's name, ID, etc. You'd also perhaps want to do error checking there like seeing if the expecting number of rows was obtained. It's totally fine to pass data into the constructor, but you'd probably want it to be eg, a string name, an int ID, etc as opposed to a DB cursor (or similar).
    – Kat
    Jul 18, 2017 at 20:10
1
  • If by data you mean a resultset or a cursor, them NO, a DAO should not return that.
  • If by data you mean a string of comma-separated values, a JSON string or a business object, the it is OK. In the cases of reports, a string of comma or TAB-separated values seems like a very good option.
Improve this answer
1
  • 1
    Returning something like a JSON object is totally fine. But if there exists some business logic object like Student, you should return that as opposed to simply the exact data that would normally go into a Student.
    – Kat
    Jul 18, 2017 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.