Databaseless ASP.NET MVC 5 on top of an external REST API

Question

Where you would envision an out-of the-box ASP.NET MVC 5 web application on top of an MSSQL database, I have now been placed in a situation where I'm supposed to use custom external token endpoints and use bearer tokens to make authenticated API calls.

I'm, de facto, attempting to create a(n as) databaseless (as possible) ASP.NET MVC 5 web application.

These phases are, perhaps not by the book, but successful:

• custom OWIN middleware that uses these token and auth endpoints
• an in-memory identity that is constructed, based on what I get back from the user endpoint and that contains, among other things, the bearer token and roles as external claims, all of which are brought to the front as true Identity Claims.
• The ability to make authenticated API calls to this external RESTful API and GET/POST data using said bearer token (using RestSharp).

Now I find myself at something of a crossroads:

• I'll need to figure out how to implement Identity Roles and make it work for me to allow / shield some content and functionality based on the roles I get from the endpoint response. These are pretty much hierarchical (admin, keyuser, user).
• How will I need to proceed as I have no O/RM layer? I would imagine I would simply continue to create my own domain models and viewmodels as needed?
• I'm trying to figure out how to do all of this as "dbless" as possible, possibly avoiding altogether the infamous tables normally generated by ASP.NET for its Identity dirty work. Or will I unavoidably run into the need to persist at least some data myself?
• If necessary, I might be able to convince the backend guy to grant my wish and store (POST) my arbitrary Claims (e.g. user adds his phone nr).
• I've been working on my own ApplicationUser, UserStore, RoleStore, UserManager etc. classes. Is this the way to go? Will I even need them in this case?

At this point I'm pretty lost as to how I should proceed. Does anyone have any experience "shelling" an MVC 5 app on top of an external RESTful API without an ApplicationDbContext and what pitfalls should I be mindful of?

As you can imagine, I'm having a crisis of faith here. I'm "winging" a lot of unknowns and am glad I've gotten this far, but I'm wondering if, at all, it can be done completely, as I'm also learning Identity "on the go". It's not a great scenario, but it needs to be done within a limited time frame.

Information about what I'm attempting to endeavor is non-existent...

Any insight would thus be awesomely appreciated.

Answer 1

The fact that the data store lies behind a RESTful API is irrelevant if your have an architecture that doesn't care about how the data is persisted. It only needs to know about an interface that promises that persistence. The Repository pattern excels at creating this abstraction.

Keep in mind that if you keep your interfaces small, it would be easy to even have multiple different persistence mechanisms if you later determine that you do need to keep some information in a "local" db. Some repositories could be implemented by calling the web service. Others could be implemented by reaching into a database, or even an XML file. Again, the point being that your controller shouldn't care about how the data is actually persisted. It just calls into an IFooRepository to get what it needs.