The Solution of my application contains multiple projects.
The IAuthenticator contains an IAuthService and an IAccountStore instance.
The IAuthService is for doing the real login. It communicates with a data source like an API or database. The interface is in the Domain project, the implementation in the "implementation project" (item 3 in list above).
The IAccountStore is for storing the User object when logged in.
Everywhere (like in ViewModels) where you need to know the User, the class has an IAccountStore constructor parameter so it has access to the account store that keeps the state.
Now the problem is, I am implementing services (project 3) and need a reference to the current User. I could just put an IAccountStore in the constructor of my service implementation classes and it will automatically be populated with the global AccountStore instance. But the IAccountStore is in project 1 (UI layer) and I only want that project 3 depends on project 2.
Dependencies are now:
project 1 depends on 2
project 2 depends on nothing.
project 3 depends on 2
I could move the logic for storing authentication state (the User) to project 2, so IAccountStore will be in project 2. But isn't this a bad solution, because this is not really like a 'service'? It's actually kind of pure state and I thought it would be better to have as little as possible stateful logic in the domain layer.
- Project for the View and ViewModel layer (the UI layer). Contains (custom/user)controls, commands, converters. And it also contains "stores" that keep state of the application. Like classes for navigation state, session token when the user is authenticated, etc. These are purely for storing/changing state.
- Project for the Domain layer, which defines interfaces for services and contains Models and business logic.
- Project for concrete implementations of services, that implements the interfaces of the Domain project. For example, here is implemented how data is loaded (like getting thing from a specific API or a database, or...).
The IAuthenticator contains an IAuthService and an IAccountStore instance.
The IAuthService is for doing the real login. It communicates with a data source like an API or database. The interface is in the Domain project, the implementation in the "implementation project" (item 3 in list above).
The IAccountStore is for storing the User object when logged in.
Everywhere (like in ViewModels) where you need to know the User, the class has an IAccountStore constructor parameter so it has access to the account store that keeps the state.
Now the problem is, I am implementing services (project 3) and need a reference to the current User. I could just put an IAccountStore in the constructor of my service implementation classes and it will automatically be populated with the global AccountStore instance. But the IAccountStore is in project 1 (UI layer) and I only want that project 3 depends on project 2.
Dependencies are now:
project 1 depends on 2
project 2 depends on nothing.
project 3 depends on 2
I could move the logic for storing authentication state (the User) to project 2, so IAccountStore will be in project 2. But isn't this a bad solution, because this is not really like a 'service'? It's actually kind of pure state and I thought it would be better to have as little as possible stateful logic in the domain layer.
Last edited:
