Agreed, we've solved this issue by not returning the EF classes, rather we convert to models and return them instead of the EF class. Inbound requests use the model as well. All of our EF work is fully contained within each endpoint method. We do not maintain state on our endpoint 'sends and receives' with respect to EF, we allow the object mode mutation to happen in client of which when it is "posted" or "put" back we allow the action to define the meaning.
Posted = new, Put = update. After all if the front-end is doing validation who is the back-end to argue?
Exactly what I did for former client. I made dtos, domain models, and ef models. Made inernal classes that extend domains with transformations only in specific packages like controllers are in same DLL as internals that have toDto and toDomain or reposistory dll for ef. Every developer hated me on the project since it was not possible to go from DTO to EF model in1 step or save DTO directly. You had 2 transformations each time you want to save or return.
Not actually, I did started something like CQRS but not actually following that particular pattern mainly because I didn't care enough to learn it in details. I just made some DTOs that are basically commands but I still keep same models for update and add mainly. Just some times I have different Add nad Update models (commands). As for query I mainly have those as models when I take more than 3 arguments on an endpoint which happened from time to time but I didn't care enough to transform them into special cases. I just used them in like "common" package or so
Same exact feeling I had about it all those years ago when Deno Espisito ran articles on it. That's why I was asking you to see if I should look into it again. Tx!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agreed, we've solved this issue by not returning the EF classes, rather we convert to models and return them instead of the EF class. Inbound requests use the model as well. All of our EF work is fully contained within each endpoint method. We do not maintain state on our endpoint 'sends and receives' with respect to EF, we allow the object mode mutation to happen in client of which when it is "posted" or "put" back we allow the action to define the meaning.
Posted = new, Put = update. After all if the front-end is doing validation who is the back-end to argue?
Exactly what I did for former client. I made dtos, domain models, and ef models. Made inernal classes that extend domains with transformations only in specific packages like controllers are in same DLL as internals that have toDto and toDomain or reposistory dll for ef. Every developer hated me on the project since it was not possible to go from DTO to EF model in1 step or save DTO directly. You had 2 transformations each time you want to save or return.
Did you ever get into CQRS? Is CQRS similar to this concept?
Not actually, I did started something like CQRS but not actually following that particular pattern mainly because I didn't care enough to learn it in details. I just made some DTOs that are basically commands but I still keep same models for update and add mainly. Just some times I have different Add nad Update models (commands). As for query I mainly have those as models when I take more than 3 arguments on an endpoint which happened from time to time but I didn't care enough to transform them into special cases. I just used them in like "common" package or so
Same exact feeling I had about it all those years ago when Deno Espisito ran articles on it. That's why I was asking you to see if I should look into it again. Tx!