I'm having hard time wrapping my head around on how to properly design my models in a console application while still trying to take advantage of EF core. For a bit more context, in a ASP.NET project you mostly only have to deal with a single request and is more "isolated" while the console application can grow infinitely more complex by having to maintain state and keep track of data.
For example, lets have a GameInstance which represents the current state of a game with active players connected to it. When the game starts, its state is loaded from a database using GameEntity model. While the game progresses, we need to save its state.
The first thing that comes to mind is to structure the following as:
public class GameInstance
{
private int Id { get; }
public string Name { get; private set; }
public string Description { get; private set; }
public int Score { get; private set; }
private List<NetworkConnection> connectedClients;
public GameInstance(GameModel model)
{
this.Id = model.Id;
this.Name = model.Name;
this.Description = model.Description;
this.Score = model.Score;
}
public void SetDescription(string description)
{
using (DbContext db = new DbContext())
{
GameModel model = new GameModel()
{
Id = this.Id,
Description = this.Description
};
db.Attach(model);
model.Description = description;
db.SaveChanges();
}
this.Description = description;
}
}
public class GameModel
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public int Score { get; set; }
}
But the drawback is pretty clear. All changes made require the database model to be reconstructed constantly which looks clumsy. Its also not great for allocations.
The second option is to store the GameModel inside the GameInstance and redirect the properties directory to the model itself. All changes can now be done directly to the model itself. Keeping the model around sounds more appealing but feels wrong.
The third option is to just have one class, the GameInstace and then configure EF core using the fluent API to do the right thing. This simplifies this scenario a lot and all changes can be done directly to the used instance. However, now you might need to introduce some database specific fields to the instance itself and the mix of properties required to keep track of the state. It feels like the single responsibility principle starts get cracks here. Also it makes it more difficult to use domain based architecture.
When dealing with REST requests in ASP.NET the user input comes in its own model like RequestModel. Then that is used to query the database to retrieve DatabaseModel and the required changes are done with the data from the request. Then the response is send with ResponseModel and all the objects can now be discarded and the single responsibility holds. It feels like EF core fits here perfectly. I don't feel the same with my console application.
How could I apply EF core to the console application cleanly? Am I missing something obvious? Am I overthinking this?
