Project Rename

[jdubar]

Renamed project name from RoyAppMaui to RoyApp

[bechtd]

That's a lot of file updates

[jdubar]

That's a lot of file updates

Sure is. I got tired of looking at the Maui suffix I used. I only named it that way because I had another RoyApp repo (which used winforms) and didn't know I could just fork off of it, so I created this repo. I've learned a lot since then.

So, yeah, every single file needed to change since the root namespace changed 😞

[bechtd]

I understand this (creating separate forks for different UIs).
One thing I want to try to experiment with in one of my repositories, is having different UI projects (which then also tend to have the Program/Main, program start file, being that the software tends to start from the UI-down).

So, my point being ... in theory ... it's you can have both UIs, under the same solution. It does make your builds more complex, in that you probably need targeted builds (separate yml) that don't start from the solution file, but rather from the Top-level UI Project file. And both can trigger with PRs and commit-changes. However, GitHub Actions supports all this, if you learn the nuances.

This interconnects with why I wanted to make multiple projects in the Update Assistant rewrite solution. When you separate:

1. Logic layer
2. Database access
3. File system access
4. UI layer
5. Domain concerns (common to all other layers)
6. other focused slices

It challenges you to honor these separators, and to keep "concerns"(focuses) from bleeding out of one layer and into others. It often requires more surrogates and mappers, but ... in theory ... it ends up reducing complexity and strange behaviors.
This does take effort, but it puts you in a mindset about your external, hard dependencies. And UIs and frameworks (MAUI, WinForms, WinUI) are opinionated, hard dependencies. IF you can keep those from bleeding into the middle, your core code is more "portable." You focus more on your domain concerns (the true "business logic"), in the middle, and learn to keep the UI isolated, because UI frameworks ... they come and go. A well crafted core domain (the middle logic with no hard dependency references) can survive the coming and going of UI preference shifts, or OSes, build/deployment systems.

When you force yourself to have more than one Top-level opinionated UI (MAUI with Blazor, Pure MAUI, WinUI, even console/CLI, React.JS), inside the same solution, you force yourself to "find the seams" between the layers. You are forced to very carefully consider "where does this code belong? Functional Core, or Imperative Shell?"

This isn't easy, especially as you are learning newer (or new to you) frameworks, but I believe this is how you build better software, easier to automation test software.

I want to try this, for the first time with my repo. I choose a relatively simple game program for this exact reason. The core game engine isn't complicated. The UIs shouldn't be complicated. They should be imperative shells. I want to experiment with this. I need to. And I want you to see this and challenge me, honestly. It's a learning process, but I believe the effort will make for better project designs that translate to better design in our professional work. Ones that don't require "complete rewrites" every time the "new hotness" comes out and Mgmt is telling us "you must now use this tech stack." It would merely be a new project added to the existing solution, a new integration point.

[bechtd]

Also, you don't have to have multiple build files. You can have one build with separate parallel jobs, each targeting different level UIs/frameworks, each running on different machine types.
You already know this, parallel jobs, and conditional running.

GitHub actions even supports this with matrices, environments and other mechanisms we haven't even explored.

The build script is itself programming too, with variables and reusability, IF you can see it and understand your tool (GitHub) capabilities to their full extent.