Home/ Questions/Q 7613051
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T02:04:27+00:00

This is more of a pattern oriented question as opposed to a language-specific one.

  • 0

This is more of a pattern oriented question as opposed to a language-specific one. Suppose I have a User object that is of the form:

class User
    var id
    var email
    var password
    var dateCreated
end

Two common approaches that I’ve seen to persist a User object are as follows:

// Approach 1
new User(id)
    ->setEmail(email)
    ->setPassword(pass)
    ->setDateCreated(date)
    ->saveNew()

In this approach, the User object has each property set and then the saveNew method will build up the proper insert statement to execute on the database using the properties that were set on the User (e.g., insert into user values (this.email, ...). Another approach:

// Approach 2
new User()->saveNew(User userObj)

In this example, you see that the save method, although an instance method, is sort of being treated like a static method in that it is being passed a populated User object, not working on it’s own data, which in turn builds up the proper statement (e.g., insert into user values (user.email, ...)).

The second approach, to me, feels a little wrong. But, that’s why I’m asking you. As a continuation, let me ask you a similar question. Let’s say, we want to fetch a User. We can do something like the following:

new User(id)->fetch -or- new User()->fetch(id)

Now, in the fetch method, I’ve seen these 2 approaches:

function fetch
    result = db->fetch('select * from user where id=this.id')

    user = new User()
    user->setId(result->id)
    user->setEmail(result->email)
    user->setPassword(result->password)
    user->setDateCreated(result->dateCreated)

    return user
end

-and-

function fetch
    result = db->fetch('select * from user where id=this.id')

    // We can set the properties directly or through their 'setters'
    this->id = result->id
    this->email = result->email
    this->password = result->password
    this->dateCreated = result->dateCreated

    return this
end

Returning a new User object as opposed to setting the properties of this seems counter intuitive, but I see it places. Does all this matter? Is there a proper, pure way to do it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The second approach feels not a little wrong to me. If a method is used like a static method, it should be a static method, period. Creating an instance of a class with the sole purpose of being able to invoke a member method on it, which actually works on another, totally unrelated class instance passed as a parameter to it, is IMHO ugly, wasteful and hard to read at the same time.

    OTOH it is usually not the best idea to have the class bear the responsibility of persisting itself (apart from small and simple systems). This approach does not scale. If you have the persistence logic scattered all over the place, it will turn into a nightmare if the need arises to migrate to a different DB. Persistence is a concept orthogonal to the idea of representing a User, so it is best to handle it in a distinct class. Such classes are often called Data Access Objects (DAO). Using a DAO may look like this:

    dao = new UserDAO()
...
user = new User(id)
user->setEmail(email)
user->setPassword(pass)
user->setDateCreated(date)
dao->save(user)

...

user2 = dao->fetch(id2)

    This separation of concerns isolates your domain objects (entities) from the nitty gritty details of the persistence mechanism. This may enable you to switch to a different persistence provider, or even use multiple persistence mechanisms in parallel, without touching your domain objects. (OK, in practice it is not always so clear cut, but still this is usually a step in the right direction.)

    • 0