Simplify application maintenance

[RonnyB71]

Introduction

In order to reduce breaking changes in the template used by all Altinn 3 Apps and to simplify the maintenance of apps a number of issues have been identified and grouped into this epic.

The expected positive results are:

• Smaller interfaces is easier to implement and reason about as well as test.
• Easier to swap out and replace if our default implementation isn't what's needed.
• Less Altinn specific and closer to standard ASP.NET, making it easier to onboard new .Net developers as it's closer to what they already know about .Net developement.
• Loosely coupled components
• Fewer breaking changes
• Removes the need for application developers to change override methods from AppBase that they haven't touched/used as part of we introducing new changes.
• Prepares the ground for easier code re-use for example by creating standard codelists that can be injected into any app.

Not solving:

• The need for an application owner/developer to have to keep their app updated with the latest nuget packages and security patches and deploy those changes.
• Breaking changes altogether. Breaking changes can still happen and relies on how well the interfaces are defined.

In scope

• Although the details isn't in place yet the goal is to split todays interfaces and implementations (eg. IAltinnApp, AppSettings +++) into smaller interfaces and move code out of AppBase into default implementations with the ability to easily swap them out if needed.

• Create a .Net Api on top of the configuration we currently have. This is more about restructuring the standalone service implementations we currently have, where the responsibility of knowing what files needs to be updated is exposed to the controller, into a business layer handling all the implicit connections between the various configuration files.

Out of scope

• A DSL for building apps without having to resolve to C# or JavaScript coding for simple applications. The issues in this epic is considered necessary and a good help if we later decide to create a DSL. Although a good idea, we currently don't have the resources to take on this task and we need to prepare the underlying codebase (this epic) to make it easier to have a DSL on top.
• AppLight - a concept where the all the shared runtime code was separated out into it's own container allowing for only the configurations to be injected in order to create the application. The reason for not including this is that it might be that the work done in this epic is enough, or at least we would like to evaluate the results before taking the next step and the fact that you would still need to deploy the app in order to get the latest version of the app.

Tasks

app-template-dotnet (in prioritized order)

• Drop the need for overriding AppBase.cs #111
  Goal: Base overrides on Dependency Injection with well defined interfaces instead.
• Simplify Program.cs in app template #109
  Goal: Get a better distinction between custom services/config done by app developers and default/required services/config added by Altinn team, ease the job required when we need to change this file, have a smaller file and separate out our and app developrs registrations in separate classes (to some point what's done with AddAppServices and AddPlatformServices today).
• Remove duplication of app template --> Move template to separate app-templates repo altinn-studio#3647
  Goal: Re-use the publised version of the app-template directly
• Establish test per major version of the nuget packages #112
  Goal: avoid having to refactor existing tests that targets the current version. Have tests on each supported version and ensure that no breaking changes are introduced when doing minor/patch updates.
• Restructure app template (code and files) to adhere to default .Net Analyzer rules #110
  Goal: Have the same set of rules applied to the development of apps and the app template as we have everywhere else. Avoid warnings and ignore statements in code when we pull app code into integration tests. We should have a warning free template to lead by example.
• Extend app template with test project #120
  Goal: Run tests as part of apps pipeline and encourage best practices.

app-lib-dotnet

• Establish new project structure and namespaces #108
  Currently we publish 3 nuget packages, but we treat them as 1 - meaning we always publish all of them to keep them in sync. We should look at the need for having 3 separate packages, and perhaps start of with one and discuss the need for multiple when the need arises.
• Move from AppBase and overriding methods as extension points and over to dependency injection and dotnet event pattern #114
  Goal: Reduce breaking changes when implementation changes as the base class approach is sensitive when it comes to introducing breaking changes.
• Split AppSettings into smaller classes based on IOptions<> #113
  Goal: Group settings that belong together in the same class avoiding to have dependencies on settings not related to the actual use. Eg. Eformidling settings should be on their own.
• Move EFormidling logic out of AppBase #115
  Goal: Register, configure and inject EFormidling only when the app actually uses it. EFormidling should be a separate nuget package and is a good candidate for testing that an "add-on" like this can be configured only through importing the package and register the necessary services. This means we need to have interfaces defined that allows EFormidling to be injected and executed at the right places ref. Move from AppBase... task.
• Move PDF generation out of AppBase #116
  Goal: Allow for easy replacement of PDF generation, both for Altinn to create a new version and for app developers to create their own.
• Consider moving Altinn2Provider for AppOptions out into a separate nuget package #117
  Goal: Reduce core and have smaller packages for additional implementations. Same is done for a new package specifically for Altinn 3 which eventually will replace the dependency on Altinn 2.

altinn-studio-docs

• Establish V7 documentation ref. Keep old versions of docs when new major versions are published altinn-studio-docs#587
• Update training documentation #118
  Goal: Training need to reflect the new ways of extending an application with custom code.
• Verify that other documentation is still correct #119