5

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;
  }
}
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;
    } 
}
  • 1
    Thanks - Why should I avoid passing data to the constructor? – Nik Kyriakides Jul 13 '17 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 '17 at 6:42
  • 2
    done, excuse smart phone editor – Ewan Jul 13 '17 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 '17 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 '17 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.
  • 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 '17 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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