I’m looking at the Ultimate Vue template and the other booking examples.
In your service model, you have Bookings.cs, where you keep the Booking class.
I’m guessing the recommendation is to keep the classes that map to the physical database in the service model so it can be shared ?
I’d like to know how you usually manage the initial creation of your database and changes to your DataModel → Database in production.
Let’s say you change Booking and want to push the changes to your production database. What’s your usual workflow?
I usually maintain a separate model_db, and I have a console application that drops all the model_db tables and recreates all the tables, etc. After that, I use DbForge Schema compare to compare model_db and the production db, generate the SQL statement to update the production db, and push the changes.
We have a Migrations workflow built into the templates that use a database for examples like bookings.
This will keep your deployed at in sync with your data model. Alternatively, if you want more control, yes, keeping your API DTOs vs Database Model separate can help you have more flexibility with your internal DB structure, at the cost of some complexity you will have to manage. Using features like database Views can also be useful since you can use DTOs with OrmLite to map data from your own custom Views just like you can tables.
AutoQuery endpoints combined with migrations is a low effort way to have your data easily queryable, we’ve found this works great for admin APIs since your database model and APIs automatically stay in sync as your DB model gets updated.
You can checkout our BlazorDiffusion example application Migrations folder if you want some reference code, we also have more tutorial videos on our YouTube channel, and in our docs.
