I have a series of nested objects, exposed over a REST API, like so:
class Categories
{
int id;
string name;
List<Subcategories> subcategories;
}
class Subcategories
{
int id;
string name;
List<Products> products;
}
class Products
{
int id;
string name;
List<Models> models;
}
These objects can be accessed over a REST API with the following end points
// get a list of categories
GET /categories
// get a category
GET /categories/:id
// Get subcategories for a product
GET /categories/:categoryId/subcategories
// Get a subcategory
GET //categories/:categoryId/:subcategoryId
//Get products under a subcategory
GET /categories/:categoryId/:subcategoryId/products
//Get a product
/categories/:categoryId/:subcategoryId/:productId
//Get models
/categories/:categoryId/:subcategoryId/:productId/models
Get a model under a product
/categories/:categoryId/:subcategoryId/:productId/:modelId
What design pattern do I use to design a data access layer on the client side?
Please note that my client only reads these objects, it doesn’t write to them.
DAO? Repository? I am a bit confused between the two, not sure what would be applicable here.
5
Why do you want them nested in your access layer? That API exposes plain objects, not trees of them as I can see.
So, you may build your internal API mimicking that one.
class Category {
public static Category[] getList();
public static Category getById($id);
public static Subcategory[] getSubcategories($id);
public void fetchDetails();
}
class Subcategory{
public static Subcategory getById($id);
public static Product[] getProducts($id);
public void fetchDetails();
}
I’ve declared some methods static, but just for clarity sake. In most cases static method on classes may prove testing hard.
In this example created objects are empty by default. fetchDetails() method fills them using REST API. This is to skip one API request when you want to fetch only children of a specific parent without fetching the whole parent first.
Well, as I said, it’s only an example. Without the specific requirements of API consumers it’s hard to suggest something really useful 😉 And requirements tend to change ;)))