Hello Dev Community! 👋
It is officially Day 52 of my daily coding run toward full-stack engineering! Yesterday, I configured dynamic updates and query string checks. Today, I scaled my Model architecture to an enterprise tier inside Prashant Sir's backend masterclass sequence: Implementing multiple independent OOP Models to decouple unique app domains!
Instead of creating one massive chaotic model or loose functional files to update state metrics, I engineered two completely independent, decoupled class layers: a catalog model (houseList) and a collection tracker (favourite).
🧠Key Learnings From Day 52 (Dual OOP Model Schemas)
As shown in my codebase views across "Screenshot (120).png" and "Screenshot (121).png", mapping domain operations into separate classes is critical for maintainability:
1. The Core Item Entity Model (homes.js)
My houseList class maps all core product attributes via its constructor (houseName, price, location, rating, photoUrl, description). In its .save() routine, it dynamically branches: if an ID exists, it runs a .map() iteration to edit the target record; if not, it assigns a random dynamic identifier token (Math.random().toString()) to initialize a fresh record safely.
2. The Relationship Matrix Model (favourite.js)
To track user selections without cluttering the master catalog, I built a secondary standalone class: favourite.
- It writes target selections straight into a dedicated data file:
favouriteData.json. - Includes advanced nested array cross-referencing capabilities using static methods to filter product matrices:
javascript
// A conceptual look at cross-model filtration from my workspace today
static favouritefindById(callback) {
favourite.fetchAll(favouriteId => {
houseList.fetchAll(registeredHomes => {
let favouriteList = registeredHomes.filter(home => favouriteId.includes(home.id));
callback(favouriteList);
});
});
}
Top comments (0)