1

As far as I know, the DBContext or underlying persistance technology should be only contained inside the Data layer.

Also, it feels very wrong to me to have identity package inside the user interface layer. The identity should be the responsibility of a centralized business layer, which in case should be usable by other parts of the application (e.g. wpf, forms, web-api projects etc), and not just asp.net front-end.

If I separate the identity to another layer, this partially solves the problem, but this time, I have to specify the DBContext inside the Startup.cs file for front-end, which should only reference Business Layer and work with View Models or DTO's.

The business layer should provide the authorization/authentication services, and attributes for decorating relative methods for permissions.

Anything with the name "ASP.NET" should be contained inside the user interface layer.

Also, the dependency injection framework should also be partially configurable across layers of the application, which should permit specifying required instances of specific classes inside that layer.

I'm extremely confused about the choice of architecture in .NET Core.

Please guide me to the right way of creating the right architecture.

Thank you.

Improve this question
  • 1
    To answer the question in your title: yes Identity is a leaky abstraction. But not for the reasons you cite. For example, you must call SupportsUserRole on Usermanager to find out if it implements IUserRoleStore, thus exposing the inner workings of Usermanager. – David Arno Oct 11 '19 at 9:58
  • 1
    The body of your question is confused though. Startup.cs is not "the front end". It's the start point of our entire application and it, with the help of an IoC container you may choose to use, is the only place where the concrete DBContext should be decided upon and supplied to the business layer for example.It's unfortunate that the "main" of a ASP.NET Core app has to be located alongside the front end, but that doesn't make it part of the front end. – David Arno Oct 11 '19 at 9:59
  • Thank you very much for the response. As I said in my question, if there should be a centralized place for setting up application wide settings like DI, it should be in another section, or my confusion is beyond the limits of normal :) – Excessive Oct 11 '19 at 10:34
  • 1
    @DavidArno: "is the only place where the concrete DBContext should be decided upon" Not necessarily explicitly. You can defer the specific context registration to a DAL component, which gets called from Startup.cs. That way, you avoid needing a direct EF reference in your top-level project. You're right that the dependency registration needs to originate from there, but that's not exactly the same as needing to handle the exact dependency types there. – Flater Oct 11 '19 at 10:53
  • @Flater, fair point. Thanks for clarifying. – David Arno Oct 11 '19 at 10:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.