How to structure a solution by separating Webapi from Webui using ASP.NET Identity?

Asked

Viewed 732 times

8

How should be organized a solution that will have at least three projects, being them:

  • Class Library as infrastructure
  • Web Application as Web Api
  • Web Application MVC for Webui (user interface)

Where ASP.NET Identity will be used as an authentication and access control component.

That is, something from ASP.NET Identity goes into the Webui project (Asp.Net MVC)? What?

c# asp.net-mvc entity-framework-6 asp.net-identity

  • You can customize the Asp.net Identity, thus creating a service that meets these projects

2 answers

2

The shape I use is:

  • MeuProjeto.Dominio (Models, Enums, Helpers and Non-visual Extensions, ASP.NET Identity);
  • MeuProjeto.MVC (Controllers, Views);
  • MeuProjeto.WebApi (Apicontrollers).

Both the Entity Framework and ASP.NET Identity must be installed in the domain. ASP.NET Identity must be installed in the MVC and Web API applications, at least the Core and OWIN packages.

1

The ideal is to isolate your Aspnet Identity from your main project, as it has responsibilities and rules that only belong to it and should not be mixed with your application.

The implementation of Aspnet Identity is not a layer of your solution, it is part of your infrastructure, having a "behavior" of Crosscutting.

I have in my Github repositories an example project Webapi with Isolated Identity. It is complete, has even a web project running a SPA application just consuming the Webapi.

  • This is not exactly true. ASP.NET Identity is strongly coupled to the Entity Framework. What is recommended to do is to use a server completely isolated from the solution, and the solution only consumes methods from this server. Identityserver is one such implementation.

  • Yes, @Ciganomorrisonmendez, I said that you should isolate Identity from your application/solution and not from any other library/component. You can isolate in a project just for it, or even isolate on a server. But, of course, you should not avoid using EF. I even recommend EF to Indentity, even if your main application opts for another ORM.

  • Still, I am quite resistant to believe that your proposal is a good idea. If I want my domain to make use of the entities that ASP.NET Identity generates for me (for example, the entity ApplicationUser can be strongly related to other entities by FK, for example), this separation makes even less sense.

  • Well, you can do that, of course. I would never, ever support making the domain depend on an infrastructure. The contexts are different. The application domain should not have authentication data, it is not its responsibility.

  • @Ciganomorrisonmendez, I forgot to mark you in the comment above. :)

  • I honestly don’t know where that came from. I’ve never seen written anywhere by Microsoft, except by some people who insist on such techniques and, in my opinion, do not represent any gain in productivity, security or system quality (curiously, all Brazilians). I think that this concept of cross-Cutting within ASP.NET MVC.

  • O Identity was made to depend on the RU, and therefore on a domain, and you can write another storage provider if you want, and that’s it. It’s not an independent aspect of the application. It’s not a consumable service. It is a highly domain-coupled authentication and user control architecture.

  • You don’t have to mention me. When you answer, I get the notification ;)

  • Let’s go continue this discussion in chat.

Show 4 more comments

Browser other questions tagged c# asp.net-mvc entity-framework-6 asp.net-identity

You are not signed in. Login or sign up in order to post.