Following an article exploring WPF multi-process UI (Like Chrome), we found a relatively reliable way to deliver WPFUI across processes. This article will design the WPF multi-process UI framework.
Functional requirements
- A main process serves as the host for the UI of multiple child processes
- Each subprocess is independent of each other
- Main process and child process can be flexibly disassembled and assembled
- .
Nonfunctional requirements
- It has little impact on the existing development model
- Support for potential plug-in extensions
- Unit test coverage >60%
- .
Design Scheme 1
The host program starts a new empty process as a child process. The AppLoader is used to load the content of the real child process. This method does not limit the form of the real child process, which can be an EXE or DLL. The downside is that the child process can be complicated and the AppLoader implementation can be cumbersome.
Design Plan 2
This scheme is simpler than scheme 1, which directly starts the child process in the host program without AppLoader. However, this scenario requires that the child process be an EXE program.
Logical View
Process View
instructions
The point that needs to be emphasized is
- The main process manages the UI of each child process
- The child processes do not affect each other
- The use of MAF