-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create data models #312
Comments
This might want to wait on refactoring abilities to be ECS to avoid messing around too much with inheritance in the data model #159 |
On the other hand, refactoring the data classes out would tell me what need to be decoupled inheritance-wise... |
That PR didn't actually create the data models, but there was some refactoring I wanted to merge. |
Made another attempt at this, but the class I chose to data-fy was Hull, which wouldn't work being a generic class, so I tried with not much luck to de-generify it. Maybe this could be revisited after #53 is dealt with, or maybe pick another class to data-fy. Really though, there aren't that many GameReferences in the game to begin with, but it would be nice to make the serializer able to handle changes to classes! |
What needs to be cleaned up?
Right now our data models are mixed up with our domain models. This eliminates duplicate code, but makes the models very brittle as any change to the domain model necessitates a change to the data model and vice versa because they are one and the same.
Also let's rename the FrEee project to FrEee.Core to clarify what it is. Maybe put the data models in a separate project called FrEee.Data referenced by FrEee.Core and that alone, to enforce separation of concerns.
How will this benefit us?
Creating separate domain models will make the code flow simpler and more flexible.
What potential drawbacks are there to making this change?
Duplication of code (the reason this wasn't done to begin with)
The text was updated successfully, but these errors were encountered: