Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Mapperly – A .NET source generator for object to object mappings

github.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#51

Post by naasking »

bob1029 wrote: post #31

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?

> Reflection is very accessible and we have managed to avoid severe penalties of this on most paths so far.

Performance is not the main issue, it's future changes breaking something that can't be checked at compile-time. Source generators can't break in this way.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#52

Post by 0x445442 »

functionstooge wrote: post #20
neonsunset wrote: post #12

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.

I'm curious, why would this be bad? I've generally always seen it as best practice to create classes in your domain model and try to write your ideal code and then have separate classes/DTOs that are used for communicating outside your domain model such as reading/writing to a database using an ORM or responding from an API with your ideal model for the consumer (since more often than not consumers don't need or want…

> customers don’t need or want all of the cruft inside the domain model and your DB…

Why would the customer need to know about the cruft? The view/UI shouldn’t be exposing what’s not needed. Same with the DB, frameworks like MyBatis put the mapping where it belongs.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#53

Post by hateful »

Yuioup wrote: post #9
royjacobs wrote: post #3

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.

I banned Automapper from my company.

For me, it's been great for mapping the Domain objects to API Response objects. I wouldn't recommend using it to map your Dto objects to your Domain objects. At the end of the day it helps to solve the problem of multiple API responses sourced from the same Domain object. For example, the "Product" object in a list of "Products" may not have the same fields as the "Product" object in the "Product Details".

I'm curious, what do you use for this use-case, if you have it, in your company?

(of course, everything is dependent on the particular project's needs)

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#54

Post by moxplod »

This has always been a pain. One recent improvement has made it better though. The new VS IntelliSense that generates code for you creates mapping MUCH easier as it fills in the rest of the shallow copy for you.

But, now that I use rider instead of VS. That is the main feature I miss.

I will be trying this out. Thanks OP.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#55

Post by radicalbyte »

neonsunset wrote: post #48
HideousKojima wrote: post #45

Earlier quoted context omitted.

Top-level statements are actually my single biggest beef with .NET 6 and 7, specifically because Microsoft decided to make them the default for any new console apps. And they didn't even add a flag for reverting to the old behavior until .NET 7, their guides for .NET 6 if you actually wanted a proper Program.cs file were literally "Generate is with .NET 5 and then up the target framework to .NET 6." This broke over a…

That is the goal. Change is likely to cause documentation and knowledge to become outdated. Also changing the app back to old format is "Ctrl + ." -> "Change to Program.Main" away. Developers would find a gripe with one new feature or another, even if it makes achieving a particular goal easier and less painful, simply because change is very uncomfortable to many.

Yeah this! I write a lot of console apps and I absolutely love this change as it simplifies and removes a lot of cruft. Which means more people will make more console apps.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#56

Post by osigurdson »

neonsunset wrote: post #46
osigurdson wrote: post #43

Earlier quoted context omitted.

>> teams can easily maintain up to 10 or even 15 (micro)services Your arguments reject complexity, then, in the next breath, endorse it. Micro-services are the enterprise bloat of our time (and likely the worst example of all the bad ideas that have circulated in that space). Small departmental apps used by 15 people require 34 micro-services (all hitting the same db tables of course).

It all comes down to scale. I'm not endorsing splitting off logic into different applications for the sake of it - it is no better (usually worse) than splitting logic into separate modules for things that could've been "together". 34 microservices per just 15 people sounds like a lot of trouble unless those are really "lean", have little to no boilerplate and managing infra-side of things is automated away or outsou…

Services should be factored along scaling dimensions, not domain or team size. Ideally scaling and domain dimensions will be coupled to some extent, but that is not always the case. The popular idea that needs to die is that services are somehow tied to team size.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#57

Post by kaba0 »

neonsunset wrote: post #23
jcmontx wrote: post #18

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…

> unlike Go

What exactly does Go do here, besides being grossly more verbose and less expressive than C# (and even Java)?

Sure, there are edge cases to nominative typing systems, and some of these particular cases may be better expressible with a structural one, but that’s another discussion to have.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#58

Post by jnsie »

functionstooge wrote: post #21
Yuioup wrote: post #9

Earlier quoted context omitted.

I banned Automapper from my company.

I haven't used it for years and I have never looked back! Even in extremely large systems, manually writing a mapping layer is quick (although admittedly obnoxious) and has helped me identify issues so much easier.

It's been many years since I was a (.NET) developer and therefore since I used automapper. Are there any VS plugins that take the tedium out of this mapping? Right click on a class, choose a class to map it to, and it creates the boilerplate code for the mapping layer?

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#59

Post by kaba0 »

neonsunset wrote: post #46
osigurdson wrote: post #43

Earlier quoted context omitted.

>> teams can easily maintain up to 10 or even 15 (micro)services Your arguments reject complexity, then, in the next breath, endorse it. Micro-services are the enterprise bloat of our time (and likely the worst example of all the bad ideas that have circulated in that space). Small departmental apps used by 15 people require 34 micro-services (all hitting the same db tables of course).

It all comes down to scale. I'm not endorsing splitting off logic into different applications for the sake of it - it is no better (usually worse) than splitting logic into separate modules for things that could've been "together". 34 microservices per just 15 people sounds like a lot of trouble unless those are really "lean", have little to no boilerplate and managing infra-side of things is automated away or outsou…

The latter has API equivalency, but that is not the same thing as feature parity. Plus, you have very different concerns when you want a small self-hosted app, vs a more “traditional” deploy model where integration and the like are more important, shaping the way you program.

Re: Show HN: Mapperly – A .NET source generator for object to object mappings

#60

Post by kaba0 »

radicalbyte wrote: post #33
neonsunset wrote: post #23

Earlier quoted context omitted.

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 been programming forever now and have written a lot of C#, TypeScript (/JS) and Python - and I much prefer the approach used in ServiceStack and in Vue.js of putting the "things which belong together" in one file than the alternatives. 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…

While some tooling has trouble with many small files, I find it just as debilitating to navigate a huge C file for example, that mandates heavy jumping between different positions even in IDEs. Sure, I do know about multi-pane editing, but my brain prefers the “tab corresponds to file” abstraction.
Post reply on HN