1

I'm trying to wrap my head around OOP when building simple CRUD systems, using the Repository Pattern to handle object retrieval/saving to persistent storage.

I've already designed and implemented a system that doesn't use OOP, just straight up get, insert, update and delete functions that contain SQL queries.

Non-OOP way

For example, for updating a customer I would call this function:

// PUT customer
function updateCustomer(idCustomer, data) {
  db("customer").update(data).where("idCustomer", idCustomer);
}

OOP way

Now, to implement this in OOP using the Repository Pattern I would do something like:

// PUT customer
customer = customerRepo.getById(idCustomer);
customer.setData(data);
customerRepo.update(customer);

OOP way seems to require an extra DB roundtrip

This OOP pattern seems to require DB roundtrips since I need to:

  • Instantiate a new customer object from the DB using the repo
  • Update the data in the object
  • Save the object back to the DB using the repo

Question

Isn't my current, non-OOP way of doing things more efficient? If yes, are there any common solutions to these roundtrips when following the 2nd OOP method?

  • 1
    where do you get data from – Ewan May 4 '17 at 6:54
  • As mentioned in the question, a database. – Nik Kyriakides May 4 '17 at 14:55
  • yeah, so you are missing that step in the first example – Ewan May 5 '17 at 17:53
1

This isn't right. You're comparing two different things. A more fair and perfectly equal method for the second example would be:

// PUT customer
customer = Customer();
customer.setId(customerId);
customer.setData(data);
customerRepo.update(customer);

And in that scenario, you're also only doing one query (the update) but it's still more object-oriented. Your problem is that you're creating a "strawman" argument, suggesting that getting the customer from the database first is somehow intrinsic to object-orientation and the pattern, but that's not true. OOP, Repositories, and whether or not to get the data from the database first have nothing to do with each other.

  • I got a bit caught up in the details and in the process convinced myself that I should only instantiate Customer objects using the CustomerRepo – Nik Kyriakides May 4 '17 at 4:07
  • @NicholasKyriakides depending on what implementation of the pattern you are using, you can MERGE or "add" the object to the repository after you assign it an ID. if the repository already knows about an entity with the same identity, it can let you know. – RibaldEddie May 4 '17 at 4:09
  • @NicholasKyriakides not every ORM framework that supports the pattern will work the same way. If you're rolling your own repo then how it works will be up to you. – RibaldEddie May 4 '17 at 4:09
  • @NicholasKyriakides one thing to think about too is that if you need to ensure the integrity of your data and want ACID compliant updates, you'll need to use something like optimistic locking with an incrementing version number. And in order to make that work, you'll need to get the data from its persistent storage first to know what it's current version number is. So while not necessary, just because you're getting the data first doesn't mean you're doing something bad. – RibaldEddie May 4 '17 at 4:20
  • 1
    @NicholasKyriakides even an ACID complaint database is happy to persist data on a row that was just updated by another client, completely blowing away the contents of the previous write. As long as the constraints are satisfied, it's totally possible for one client's write to be negated just after it's committed. ACIDity doesn't mean your application handles this situation, it just means that the DB data structures aren't corrupted. You still need a mechanism for one client or connection to know that the data was changed out from under it by another. – RibaldEddie May 4 '17 at 4:33
1

I believe that for the simplest of CRUD models, even Repository is an overkill.

The main purpose of repository pattern is to allow to query rich object model, that can then be manipulated in OOP way. This sacrifices some DB queries to gain ability to manipulate data in "better" way than plain SQL.

But in your case, it seems that there is no need for rich domain model, as you seem to be fine working with plain SQL.

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.