简体   繁体   中英

Updating an object in server memory vs pulling the updated object from the database

I have somewhat of an architectural/best practices question

I have a small object, like so

userObjectFactory(data) {
  const {
    id,
    lastActive,
  } = data;

  return Object.freeze({
    id,
    lastActive,
  });
}

Now I have to ways to update it in memory. I can either recreate the object with updated value, like so

if(saveToDb().passed === true) {
  const newUser = userObjectFactory(newData)
}

or, I can save to the database, and then pull the updated object.

It seems that both of these approaches will use the same amount of code, but the second one will make one more pull from the database, which can add up.

What's the best solution here?

And the second question is, if I stick with the first option will it be better to recreate the object using the factory? Or to add a method to change a property? I'm a bit confused about the immutability principle

First off, if you can avoid writing to the database, absolutely take that choice.

Then, we could answer better if we had some context about what you're trying to protect against - whether it's just accidental changes in your own code or whether you're giving this object to other, outside code that you don't control?

If it's just your code, then you're probably overthinking things by trying to make the entire object immutable when you actually don't want everything in the object to be immutable. Some of the object is active state that can change.

For that case, I would use Object.defineProperty() and set up the actual immutable properties as {writable: false, configurable: false} and leave the mutable properties as something you can directly write to and change. You've described no reason to Object.freeze() the entire object when you actually intend to change some of the properties.

If you're passing an object to outside code and you don't want them to be able to change your actual core object, then just pass them a copy of the object, not the original. Then, no matter what they do to it, it won't affect your code in any way. Then, you're not trying to manage some sort of hybrid object that is immutable to some code, but mutable to some code which is just a bit of a mess.

And the second question is, if I stick with the first option will it be better to recreate the object using the factory? Or to add a method to change a property? I'm a bit confused about the immutability principle.

It's not clear exactly what you you're trying to achieve with the immutability principle here. It sounds like perhaps you're trying to follow some sort of design principle about making things immutable whenever you can. There are certainly places for that, but like any design principle they should be applied when they make sense and not when they don't. If you have actual mutable state in that object, you probably don't want to put that state in an object that is immutable. So, either store the mutable state elsewhere or don't pretend the mutable object is immutable (when it's not). Just like if you have an array of 10,000 items and you wish to update one item in the array, you don't make the array immutable and then have to make an entirely new copy of the array just so you can modify one item in the array. No, you mutate the existing array and change the one element directly. It's a ton more efficient.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM