CODEWITHSUNDEEP
asp.net-web-apiasp.net-core-mvcidentityserver4
pjdupreez
pjdupreez

Reputation: 717

MVC Core and MVC Core API with Identity Server 4

I have several projects done in MVC5 which I am looking at 'upgrading' to Dot Net Core with IdentityServer 4. Each project has an API through which Android and iOS clients connect. The API and MVC are in the same project.

I am currently working through the quickstart samples of IDS and have implemented IDS with and API and MVC client using the documentation found here docs.identityserver.io

I am trying to get my head around the architecture of using the MVC client with the API where only the API would have a reference to the DbContext?

Should the API and MVC Client be in the same project or in 2 separate projects?

I also assume then that data to be retrieved and saved to the database should be managed by the API only? No sense in having 2 places where Entity Framework is used (API and MVC) if I now see the MVC client in a similar light as an Android/iOS Client?

I am also assuming that Razor Views can be migrated to DotNet core easier than creating new ones?

But then there are 2 sets of controllers, one for API and one for MVC. MVC would then connect to API using HttpClient (or RestSharp?). This seams like an extremely bloated approach where I'd have to do API calls in my MVC controllers' actions. As compared to using an ApplicationDbContext?

Or am I going about this all wrong?

Upvotes: 0

Views: 302

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239240

It's entirely up to you. You can have the MVC project be a client to API project or you could simply have both projects utilize the same underlying data layer. Personally, I tend to opt for the latter. Essentially, you'd just create a .NET Standard 2.0 class library that implements a service layer. This class library would interact with your database (DbContext), and abstract the logic for the calls your MVC/API needs to make. Then, both projects can simply reference this class library, and use your service layer to accomplish what they need to do.

If you want to use the MVC project as a client, then, yes, you would simply use HttpClient to make requests to your API. RestSharp is merely an analog of HttpClient, so you can use it if you like. Personally, I don't like using third-party libraries unless they offer a significant level abstraction or other benefit not available via the platform, which I don't think RestSharp does. It's perhaps arguably easier to do some things via RestSharp than HttpClient, but not dramatically so. Any old developer can come in and work on your code that utilizes HttpClient, but you need someone specifically familiar with RestSharp to work on RestSharp code. Like I said, sometimes that's a tradeoff that's worth it, but that's ultimately something you'd need to decide. However, you might consider a library like Refit, which let's you create an interface that models your API and easily make API calls without have having to deal with the low-level HttpClient calls or the mapping to/from JSON, etc. That's a significant amount of abstraction to warrant using a third-party library.

Upvotes: 1

Related Questions