31–40 of 71 posts
That said, I have failed to find a practical use case for source generators in my day-to-day work. Reflection is very accessible and we have managed to avoid severe penalties of this on most paths so far.
Has anyone found other good use cases for source generators in their projects?
I like how everyone here and the repo’s readme talks about performance as if the problem with Automapper was the fact that it was making your enterprise app that waits N seconds for a db query and relies on caching to be even remotely usable, slow. 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 sh…
Performance is a feature. For certain use cases, it’s a top priority. It’s OK to let users know that your library is designed with performance in mind. It’s also OK to write libraries. Some people really want to write mean comments, I guess.
Earlier quoted context omitted.
In many cases DbModel is not exactly the same as AppModel and ViewModel. In typed programming languages automappers are rather useful. > without reflection Source generators are not reflection.
Yes, the above comment was addressed at most popular use case - that of back-end services where entity to class map 1:1. In fact, there is already mapping in defining DB field types (if non-default) in model registrations consumed by ORM. Worst case it is always an option to project within DB query itself, sometimes even "cheaper" too. In such cases, having an extra abstraction is both redundant and an anti-pattern t…
You see in C# and Java that people love splitting classes into files (and are forced to by automated auditing tools - my last big project suffered from that, even as Lead I had my hands tied). Navigating such projects is horrible outside of tooling (such as in github) but fine if you always work within the IDE.
In Python I'm used to wading through classes of >1k LOC which are only slightly related because they have the opposite habit. I've yet to find a way to work around this.
Honestly I'm not sure what I find worst: it really depends on the project or the domain. If I had to chose I think that I'd prefer "too many small files" to "one huge file" as the latter has an extremely high risk of turning into a "big ball of mud" and it's what the clueless beginners do. That and trauma of having to maintain some old Visual Basic system where that was the norm.
The ability to use source generators in .NET did seem like a really powerful capability when it was first announced. That said, I have failed to find a practical use case for source generators in my day-to-day work. Reflection is very accessible and we have managed to avoid severe penalties of this on most paths so far. Has anyone found other good use cases for source generators in their projects?
Earlier quoted context omitted.
In many cases DbModel is not exactly the same as AppModel and ViewModel. In typed programming languages automappers are rather useful. > without reflection Source generators are not reflection.
Yes, the above comment was addressed at most popular use case - that of back-end services where entity to class map 1:1. In fact, there is already mapping in defining DB field types (if non-default) in model registrations consumed by ORM. Worst case it is always an option to project within DB query itself, sometimes even "cheaper" too. In such cases, having an extra abstraction is both redundant and an anti-pattern t…
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.
The ability to use source generators in .NET did seem like a really powerful capability when it was first announced. That said, I have failed to find a practical use case for source generators in my day-to-day work. Reflection is very accessible and we have managed to avoid severe penalties of this on most paths so far. Has anyone found other good use cases for source generators in their projects?
Earlier quoted context omitted.
In many cases DbModel is not exactly the same as AppModel and ViewModel. In typed programming languages automappers are rather useful. > without reflection Source generators are not reflection.
Yes, the above comment was addressed at most popular use case - that of back-end services where entity to class map 1:1. In fact, there is already mapping in defining DB field types (if non-default) in model registrations consumed by ORM. Worst case it is always an option to project within DB query itself, sometimes even "cheaper" too. In such cases, having an extra abstraction is both redundant and an anti-pattern t…
In the right hands - so with strong progressive leadership - it wipes the floor with other ecosystems.
I like how everyone here and the repo’s readme talks about performance as if the problem with Automapper was the fact that it was making your enterprise app that waits N seconds for a db query and relies on caching to be even remotely usable, slow. 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 sh…
> The problem with automapper is that it throws the compiler out the window and invites all the bugs that would normally not be there. I've seen projects when Automapper was the main reason for the cold startup of an app, which caused terribly slow "write->build->run" developer experience. So it's not only a problem of runtime exception vs compiler errors. Performance also matters. > Mapping code is still your code a…
“Yeah we may risk introducing more bugs but it’s so much nicer to develop now!”
Earlier quoted context omitted.
Automapper generates all mappings at runtime with reflection. Mapperly in contrast uses roslyn based source generators and generates all mapping code at compile time. This leads to improved runtime performance with less allocations [1]. Since no reflection is used at runtime, the generated code is completely trimming save and AOT friendly. [1] https://github.com/mjebrahimi/Benchmark.netCoreMappers
And what's the advantages over Mapster? (haven't used it yet, but I see it's mentioned often as a "better Automapper" alternative)