Further separate the data access details from the Core layer

[hggutvik]

Description of noteworthy changes

1. Renaming the data layer interfaces IUserProfileClient & IUnitProfileClient -> IUserProfileRepository & IUnitProfileRepository

   • Reason: The Repository abstraction is conceptually neutral in data source implementation (the underlying datasource could be e.g. a DB, an HTTP client to an external source, a combination, ..). However, the Client concept is typically associated with HTTP clients. We don't want the implementation/data-access details of Integration to leak into the Core layer/project.
   • Consequences:
     • Practical: the abstractions IUserProfileRepository and IUnitProfileRepository will remain valid when we later change the type of data access from HTTP client to DB.
     • Functional: no change expected. Just renamed things and updated references in other files

2. public class UserRegisteredContactPoint extracted to separate file from PartyNotificationContactPoint.cs

   • Reason: public classes should be contained within files where file and class name matches
   • Consequences:
     • Practical: The class is easier to maintain
     • Functional: no change expected.

Related Issue(s)

• 194

Verification

• [x] Your code builds clean without any errors or warnings
• [ ] Manual testing done (required)
• [ ] Relevant automated test added (if you find this hard, leave it and we'll help out)
• [x] All tests run green

Documentation

• [ ] User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud