Should I 'grow' types mapped to entities with custom fields or move this logic to the controller as a separate query? #633
Unanswered
StefanGramadnikov
asked this question in
Q&A
Replies: 1 comment
-
Hey, so there is the Let me know if that helps. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm building a new structure and I'm not sure what is the correct way of handling things.
I have three tables:
Based on the three tables my FE needs to pull the following data:
What I want to build is three types classes which will be exactly mapped to my DB structure, so I will have:
ChallengeType with fields
name
,start_date
,end_date
&prizes ([PrizeType])
(prizes will come trough the relationship)ChallengeParticipant with fields
activities_type_1_count
,activities_type_2_count
&UserType
(again coming from relationship)ChallengePrizeType with fields
activities_attended_required
&prize
Then on the controller level I would have three queries
activeChallenges
-> returns[ChallengeType]
challengeParticipant
-> returnsChallengeParticipantType
challengeLeaderboard
-> aggregates the data and returns array of[ChallengeParticipantType]
The benefits I see in this from back-end prespective are:
Type classes
, which will be exactly mapped to theSymfony entities
, without any additional custom fields on themWhat my FE team suggests would be better from their prespective:
Create a
ChallengeType
with the following fieldsWhat I don't like in this approach is that I would have one bigger type and I will have to put logic for calculating the leader board and fetching the
currentStudentProgress
inside theChallengeType
.Additionally if we need more custom type fields, it will grow even more.
Essentially the question here is:
what is the better solution for putting custom logic
A. Should I keep my models slim and related to my Symfony entities and move the custom logic as additional GQL queries (controller level) or if the custom fields get too much, create a new totally detached custom type (for example
ChallengeReportType
)B. Should I freely add
custom fields
into the GQL type is most suitable for meC. Is there some other/better options I'm missing ?
I really don't like the second approach, because in the long term, stuffing logic into those types always seems like a bad idea. I really like to keep things as simple as possible and divide the responsibility as much as possible.
For example:
Controller should handle the request (validation, security, routing) and return the correctly mapped response, a service shold handle the business logic, and the Type classes should be ONLY for mapping data, nothing more.
I tried to find an answer to my question by digging trough different kind of GQL docs and articles, but nothing really gave my any helpful info.
I would really appreciate some input on this! Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions