11–20 of 71 posts
Why not just have no mappings and reuse the same objects?
Therefore, thank you for making this. Automapping is a sign of incorrect abstractions and unarguably bad solution architecture but since we are still forced to deal with such, doing so with speed and without reflection is always welcome.
Why not just have no mappings and reuse the same objects?
Something that should not be needed was just improved.
That’s yet to be seen, otherwise I wholeheartedly agree with your statement :)
The problem with automapper is that it throws the compiler out the window and invites all the bugs that would normally not be there.
Mapping code is still your code and should receive the same care as your fancy services.
I hate automapper, and I hate this too, just less because at least it has the potential to catch bugs at compile time… I think.
Some people really want to write libraries, I guess.
Something that should not be needed was just improved.
> was just improved That’s yet to be seen, otherwise I wholeheartedly agree with your statement :)
I can understand that this might be intrieging for newcomers. I've certainly learned the hard way that the only thing worse than manually writing mapping code is doing it automatically at runtime.
It is sad we still live in the enterprise world where having both "SomeClass" and "SomeClassEntity" isn't grounds for rejecting a PR that dares to do this. Therefore, thank you for making this. Automapping is a sign of incorrect abstractions and unarguably bad solution architecture but since we are still forced to deal with such, doing so with speed and without reflection is always welcome.
> without reflection
Source generators are not reflection.
I've never really understood the use case for these mapping generators. Every time I've seen them used (MapStruct in Java, AutoMapper in C#) the mapping configuration eventually ends up being so complex that just manually writing out the mapping would've been just as simple and arguably simpler to understand.
It's nice having separate classes to describe the request & response bodies because this lets you automatically generate OpenAPI descriptors which can then be used for client generation and so on.
When your domain objects are small it's easy to just manually copy the data between your domain entities and request & response objects. Once your objects grow it's convenient to just automate the mapping in a way that still gives you compile-time correctness checks.
It is sad we still live in the enterprise world where having both "SomeClass" and "SomeClassEntity" isn't grounds for rejecting a PR that dares to do this. Therefore, thank you for making this. Automapping is a sign of incorrect abstractions and unarguably bad solution architecture but since we are still forced to deal with such, doing so with speed and without reflection is always welcome.