Sometimes I forget the Razorpages is MVC under the covers. Having the need to build single-page app/responsive type web apps, I chose the following approach, and here is how the guts of the solution is laid out I setup for our team:
Web
- This is the main web app which includes an API
Models
- This project simply holds POCO classes that are passed
Data
This project holds classes that wrap Entity data models with methods for saving/fetching etc
The api uses methods in the classes of this project but accepts & returns objects of types from the Models library
The basic approach is when using controls on a page, eg. some dropdowns, a grid etc
- Initial loading of the user input controls via Ajax calls to the api
- Typically there is one main task on a page, but other things have to be loaded at different times in order to get to the point of doing the main edit/update
- Once the user inputs are provided, the data for the grid can be fetched (via jquery/ajax call to api) and the grid loaded
- jQuery code that is common to doing much of the api calls are setup in a common js library
The great thing about this approach is that it handles 99% of what we need and I don't have to replicate the model classes in something like Typescript or javascript as with other frameworks. The same POCO classes can be referenced both in the api and the razor code. Anyone that has had to replicate models i=from C# into Typescript knows what Im referring to. Yes, I had started out pushing our team to use Angular and we went down that road for over a year. It works, but was overkill for what we need. The "noise" of the various frameworks like Node/NPM and including it within a asp.net core app and the dependencies it has on the build process etc was just too much "noise". So along comes Blazor but alas it wasn't production-ready at the time we needed it. Using Razor pages with the above architecture lets one accomplish much of what one would want from a framework like Angular with a far simpler development stack.
hope this helps