Absolutely. Also, even with modern computers no game programmer worth their salt is using immutability - no matter the language - the allocation of memory and manual or automatic management of freeing it are a cost you can't afford when striving to push out the most possible performance in 16.67ms. So game programmers have to learn to not make the mistakes immutability protects from. Not that this is right for everyone, it depends on the objective.
I also get that functional programming requires it, and I do like functional programming, but there are limitations with every approach. Observer pattern seems to sit uncomfortably with Functional programming.
Good point for people that hate OOP hehe.
I use immutability regardles of the languge because you can write your own immutable data structue and it's mainly protection from DB tools like Entity Framework wich for given object to save tracks it by default and saves everything you touch after that. So if it's a service or other class it doesn't contain anything that I need to maintain so i leave it mutuable for framworks to do injections and so on. And it saves a lot of time and performance
Let's say you do ef.somerepo.update(obj) and if after that you modify obj.name or something and try to trigger ef.save() totally unrelated to previous action it modifies the object. Because anything that touches EF, if not specified, will be tracked by it.
So even if you think about it yourself some tools/people don't and this is why API developers now strive for immutable. However in many cases for complex data structure it's quite slow to do this.that.list.eachItemInIt.listInThoseItems.push... so performance in that case is on immutablity side where you just copy all of items step by step and use a bit more memory for short period in order to transform something
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!
Interesting point on Observables. They are just fancy event constructs. With the DOM only using the event event model, there really is no logical reason for anyone to dislike Observables.
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.
Absolutely. Also, even with modern computers no game programmer worth their salt is using immutability - no matter the language - the allocation of memory and manual or automatic management of freeing it are a cost you can't afford when striving to push out the most possible performance in 16.67ms. So game programmers have to learn to not make the mistakes immutability protects from. Not that this is right for everyone, it depends on the objective.
I also get that functional programming requires it, and I do like functional programming, but there are limitations with every approach. Observer pattern seems to sit uncomfortably with Functional programming.
Good point for people that hate OOP hehe.
I use immutability regardles of the languge because you can write your own immutable data structue and it's mainly protection from DB tools like Entity Framework wich for given object to save tracks it by default and saves everything you touch after that. So if it's a service or other class it doesn't contain anything that I need to maintain so i leave it mutuable for framworks to do injections and so on. And it saves a lot of time and performance
Let's say you do ef.somerepo.update(obj) and if after that you modify obj.name or something and try to trigger ef.save() totally unrelated to previous action it modifies the object. Because anything that touches EF, if not specified, will be tracked by it.
So even if you think about it yourself some tools/people don't and this is why API developers now strive for immutable. However in many cases for complex data structure it's quite slow to do this.that.list.eachItemInIt.listInThoseItems.push... so performance in that case is on immutablity side where you just copy all of items step by step and use a bit more memory for short period in order to transform something
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!
Interesting point on Observables. They are just fancy event constructs. With the DOM only using the event event model, there really is no logical reason for anyone to dislike Observables.