When it comes to OOP where an external database is being read from and written to, is it necessary to have attributes/properties within the objects to store the data? Or is it enough to simply read from the database, display it immediately, and later on directly insert any posted data back into it?

If it is necessary to have fields within the objects to store data, how/when would you read from or write to the database and update these fields?

I understand the concept of OOP and how an object should represent an entity (a thing, such as a user), but when it comes to web development, databases, and OOP I'm not sure I entirely understand how it's meant to work together.

In the past, the way I've managed this is by having objects with CRUD methods, accepting data from the view, and passing data to the controller to be interpreted for display.

I've looked at posts such as the following, but it doesn't seem to clear anything up for me: Do objects in OOP have to represent an entity?

I've also tried looking for 'OOP when working with a database' tutorials but only get tutorials showing how to create a database object and nothing that helps me understand better.


I have also seen ORM mentioned a lot as a solution of mapping a database to an object, but I still have trouble understanding exactly why you need to store the data in an object as opposed to simply displaying or storing it immediately.

  • Set first name; database query, set second name; annother database query, set email; yet annother database query. Show first name twice on a page; 2 database queries. Not saying it won't work but it'll be really slow Commented Feb 10, 2016 at 6:45
  • Never looked at it like that... So does that mean you'd retrieve all data from the database for a particular user for example at once? What would initiate the 'user' entity and keep its reference?
    – Andre C
    Commented Feb 10, 2016 at 6:49
  • 1
    Your question's title bears no relation to what you are actually asking. You are actually asking if you need to use objects to represents entities that you pulled from the database. That's nothing to do with whether object need attributes.
    – Stephen C
    Commented Feb 10, 2016 at 7:25
  • I've updated the question title.
    – Andre C
    Commented Feb 10, 2016 at 18:56

1 Answer 1


In simple cases, it is possible to read information about entities from your database query result sets and do whatever needs to be done without creating objects. For more complicated cases, it is more convenient and maybe more efficient to create objects to represent the entities. But you don't have to do that. Even in the most complicated cases you could probably avoid creating objects to represent the entities ... though you would pay a number of penalties for doing this.

It is certainly "more object-oriented" to represent the entities as objects. But there is no law that says that your code needs to be maximally OO.

The original question title asked an entirely different question:

Do OOP objects (entities) need to have attributes/properties?

The answer is that they don't have to:

  • An object can be stateless, consisting only of methods that operate on their arguments and return results.

  • An object's only state can be its identity1 ... which needs no attributes to represent. (Though if you are going to store an object whose only state is its identity in a database, then you will most likely need an id attribute to represent the object's identity (primary key) as stored in the database table.)

1 - For example, new Object() in Java is creating an object whose only explicit state is its identity. (Implicit state includes the mutex state if the Object is used as a primitive mutex, and the identity hashcode if that is calculated.)

  • I think the focus on stateless objects is the important point here. The core feature of OOP is polymorphism/dynamic dispatch. The usual implementation technique is a hidden field in each object that contains pointers to methods, i.e. the methods are the data. However, Objects frequently have no user defined fields, which is common when we only need polymorphism, nothing else. This often happens in various design patterns such as strategies, abstract factories, visitors, …. Without polymorphism, stateless objects are just a convenient collection of static functions.
    – amon
    Commented Feb 10, 2016 at 9:12

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.