0

Background

I've designed and implemented a server app - a stateless REST API that mostly deals with customer CRUD operations.

As it is now the server is designed to use modules for each functionality instead of OOP concepts - although the 2 share some analogies AFAIK.

As an exercise, I'm trying to model some aspects in OOP.

Creating a new object is straightforward.

Naturally I'd expect that creating a new Customer would simply be instantiating a new Object.

For example:

// CREATE NEW
// User wants to Insert a new customer.
var customer = new Customer({ 
  name: "John Doe";
});

return "Saved Customer";

What about getting an existing though?

What is considered a reasonable pattern if I instead want to get an existing that's already saved in DB?

For example is this a reasonable API?

// GET EXISTING
// User wants to get existing customer from DB
var customer = new Customer().fromDB({ id: 1 });

return customer;

Notes

  • I'm not using an ORM.
  • Although probably irrelevant, the app is written on top of Node.js
3

No, this is not good. A customer has nothing to do with how its saved. You could save the customer in a sql db, or a flat file, it would not change anything else that customer is responsible for, correct? Therefore, the customer should not know anything about how it is saved.

Try this instead:

// GET EXISTING
// User wants to get existing customer from DB
var repo = new CustomerRepository("dbConnectionString");
var customer = repo.getCustomer({ id: 1 });
return customer;
  • Is this the Factory Pattern? – Nik Kyriakides Apr 30 '17 at 4:10
  • 1
    No, it is the repository pattern. The repository pattern is used load/save something to/from the DB, ect, that conceptually already exists. The factory pattern is used to streamline object initialization. if we didnt want to keep on remembering the connection string, we would use the factory pattern to make the repository: var repo = CustomerRepoFactory.getCustomerRepo(); – TheCatWhisperer Apr 30 '17 at 4:15
  • Sweet, thanks. Are there other, similar creational patterns that might be relevant to DB interactions? – Nik Kyriakides Apr 30 '17 at 4:18
  • 1
    yes, but nothing you need to worry about yet imo. You need to master the repository pattern first, it sounds easy, but most people mess it up. A repository should only ever insert entities into storage, update entities in storage, delete entities from storage, or retrieve entities from storage. A lot of people will make their repositories do things like, repo.upgradeCustomerStatus() which is wrong! The correct code is, customer.upgradeStatus(); repo.updateCustomer(customer); – TheCatWhisperer Apr 30 '17 at 4:24
  • That's the insight I'm looking for. Last question - any recommended reading resources about this pattern? Ideally would include guidelines like the last one you mentioned – Nik Kyriakides Apr 30 '17 at 4:26
0

Look into caching. The way this is generally done in java is to use AOP to intercept methods that create resources, and cache them (using ehcache, redis, memcached etc.) Using a relational database as a cache is slow. Also consider orm/oxm.

  • My question was more of a design concern rather than a speed concern – Nik Kyriakides May 2 '17 at 14:39
  • Hope your severs have a lot of memory Richard – TheCatWhisperer May 2 '17 at 14:41
  • The two things are interlinked. The way you make stateless applications 'performant' (I hate that word), is to use caching. Generally caching mechanisms are designed for the purpose. Databases are not. Look into memcached which is probably available in Nodejs – Richard May 2 '17 at 14:43
  • @TheCatWhisperer Memory is cheap – Richard May 2 '17 at 14:44
  • what if you have a hundred-thousand unique users? To just say, "always cache it in memory" without knowing the request and change frequencies is absurd. – TheCatWhisperer May 2 '17 at 15:06

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.