I am surprised why this is so hard to find.
I am trying to convert my monolith to a 3 layer architecture for my node express app with a propriety sql.
BEFORE architecture change 1 file entry.js 1 endpoint with business logic Functions with raw sql that are called after validation of res.body objects
AFTER
Tech used - Using .js not .ts - nodejs - express -
Constraints - I cannot use postgres or sequlize as they don't support the propriety db that I am using.
I'll have a go at answering. I'm a database engineer and have written node.js apps that connect directly to the database without using an ORM.
1: So long as you know the structure of the data that you wish to store as it resides in the database you can write a javascript class that has methods to do all of your updating and class instantiation etc. For instance, you can have a user class with a constructor and a number of methods for creating a new user in the database, retrieving a user from the database, updating a user etc. You can read more about javascript classes here and here.
So here your Model is just a class that knows how to interact with the database.
You could store all of your SQL here, but I would advise against that in favour of using Stored Procedures in the database. That way if you ever need to tune your query, or make changes, you can change just the stored procedure without having to create a whole release of your application. Your DBAs can also tinker round with your SPs for you as well.
2: Depends what you're referring to here. A schema in the database is a container for functionality, business areas, or whole applications. Like within a business you could have a Sales schema and a Marketing schema, or you could store all of your application logic in the MySalesApp schema.
A javascript model is one particular piece of functionality and its interactions with the database. Like a user, or a person, or an animal etc. In the database all of these objects (there would probably be a person/user/animal table, with a number of stored procedures for updating, creating, etc) would be stored inside a schema. In MySQL a schema can also be a whole database.
3: You could store your SQL there. But for the reasons mentioned before I'd do this with Stored Procedures. Basically because you can tune them for efficiency without having to redeploy your whole application.
4: This also answered by using Stored Procedures. So instead of having a bunch of code that creates a user, you have an SP that lives in the database and handles everything for you. Then you just end up with a call to a stored procedure that looks like this:
var query = "BB.sp_CreateUser";
var params = [
parseInt(user.userId),
user.firstName,
user.surname,
user.userInitials,
user.telephone,
user.username,
user.password
];
let result = await database.asyncQueryDynamic(query, params);
I've got a bit of abstraction going on here because I'm using connection pools etc. But you can read more about using Stored Procedures here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With