> I also use dto's in some endpoints. So i should extend the implementation to support linq on the domain model ( on odata) and return the dto as response. But this is for later i suppose
Please don't. I've ended up maintaining far too many abominations where developers got excited about generics and linq rather than solving real problems. You just end up with apps that should be simple and straightforward being a nightmare to maintain.
Generics, linq and inheritance all have their uses but if they aren't used sparingly they create more spaghetti.
Edit - at the very least, please be careful and use generics as sparingly as possible.
Do you have any examples of how generics could create spaghetti code? Given that they aren't control flow constructs, I'm having a hard time imagining such a situation.
If you try to use generics too hard you make crazy shit. I'm working on a system that has a Something<T, Y> but the Y inherits from the T and its all just a mad mess that makes no sense at face value. I guess someone thought it was a good idea at some point but the end result is just confusing as hell.
Then you realise its just sitting upon 5 really simple Sql tables and you realise its really convoluted.
Its all about stepping back and going: "am I trying too hard?".
Like that last 10% of making the code base 100% elegant is what ruins it.
everything is great... in moderation. That last bit is what everyone fucks up (including myself in the past).
E.G. Composition + OOP is way better than "just" OOP.
Please don't. I've ended up maintaining far too many abominations where developers got excited about generics and linq rather than solving real problems. You just end up with apps that should be simple and straightforward being a nightmare to maintain.
Generics, linq and inheritance all have their uses but if they aren't used sparingly they create more spaghetti.
Edit - at the very least, please be careful and use generics as sparingly as possible.