I'm trying to create a PC version of a cord-driven turn-based boardgame. I went for the Monogame framework in c#. I'm still learning C# and Monogame and I'm reading all about how it is important to "split" the code in the data/game engine part and the graphics/GUI part. So trying to pursue this, I have the following in mind.
Graphics/GUI
Here I define all the classes relative to the screens (game - menus), GUI components like labels and buttons and possibly even mouse and keyboard inputs (the logic being the user has to click on something in the gui in order to perform an action).
Data or Game logic/Engine
Still not even sure on how I should call this part of the project, here I would put all the logic of the game. The classes of player, cards, "IA", rules etc... would be defined here.
My difficulty is now to understand how to connect this two parts but still maintain the "loosely coupled" approach. I was thinking that maybe the objects or better the instances of the game logic part would have to subscribe to events (such as button_click) defined in the GUI part...but can I even subscribe to events of another class? Is this the correct way?
I admit I'm still trying to fully understand the event driven concept, but is this the right way of doing stuff in c# and Monogame? I apologize for the vague topic/question but thanks in advance.
I don't know anything about Monogame, but generally it's a good idea to organise any kind of application into layers like this, as long as you don't make the code overly complicated by doing so. Your idea to separate the UI code from the game logic sounds like a good start.
First, think of your application as an onion, with a series of concentric layers. Your proposed structure has only two layers, but that's OK. A larger application may benefit from more layers, e.g. a data access layer if you were to store the state of the game in a database, but there's no need to add extra layers just for the sake of having more layers.
Your outermost layer would contain the UI code, typically this is known as the presentation layer.
Your innermost layer would contain the game logic, typically this is known as the domain layer. A good rule of thumb for whether something belongs in the domain layer is to ask, does this represent something that a user of your application (or a player of your game) who's not a developer would recognise?
Second, remember that each layer can make calls to code in the same layer, or to code in in other layers inside it, but not to code in layers outside it. So projects in the presentation layer can have references to projects in the domain layer, but projects in the domain layer can't have references to projects in the presentation layer. If you've got circular references between the two layers then it's a sign that something in one of the layers actually belongs in the other layer.
Here's another answer to a similar question about layering an application, albeit not in the context of a game: https://stackoverflow.com/a/70315655/16563198
On the second part of the question, if you want to use events then it's probably best to handle any events in the presentation layer and have the event handlers make calls into the domain layer (but disclaimer, I don't know Monogame).