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

61–70 of 71 posts

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

#61

Post by radicalbyte »

kaba0 wrote: post #60
radicalbyte wrote: post #33

Earlier quoted context omitted.

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.

Same here.

Although to be completely honest: I would much rather that the AST was the main interface for code. The fact that our tools are based on text is a relic of the past.

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

#62

Post by orra »

mjburgess wrote: post #27
orra wrote: post #7

Earlier quoted context omitted.

I've used Automapper a few times, in Enterprise software which takes separate layers to a dogmatic extreme. Automapper always felt like a code smell: if the layers are so trivially mappable, should they really be different layers? Alternatively, isn't automapping a violation of the philosophy of separation of layers? All that said, given these mappers exist, the fact this Mapperly does ahead of time code generation i…

I assume the automapper is subsetting on the target type's structure, right? So its something like this, target_dto = { k: MyDbModel.get(k) for k in MyTargetModel.keys() } Writing this is a big issue with simple static languages (ie., those without much compile-time programming). This deficiency should really be addressed at the language-level. Ie., what you want is structural typing in the view-layer, and a means of…

Thanks for this thoughtout reply. Automapping can also be used for renaming, and simple type conversions.

But yes, structural typing and other interesting typesystems can make this first class.

I didn't realise serious work had been put into typeclasses for C#. Interesting, but unfortunately it seems to have stalled.

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

#64

Post by f8o »

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.

Most of the time I don't need automatic mappers, but it's nice to have good, fast tools available.

When I'm building something in a more domain-driven approach, which I usually strive for, tools for domain modeldto mapping (assuming the separation between application and domain layers) does not make much sense. Because even when I have a domain model/dto pair with almost the same attributes I will be creating the model via a well named factory method in the domain layer, with notification style validation. And for changes, even for HTTP PUT, specially for HTTP PATCH, I'll be updating a subset of the attributes and for that I'll be using proper entity methods with, again, notification style validation. On both cases manual handling is the way to go.

If you're mapping lots of open fields to your domain models... it's not domain driven. Might be a choice, but should be conscious.

And if a) automatic mapping makes sense for a subset of the application, be it for api dtos or internal matters (you might be dealing with dtos internally for some integrations), and b) we'll really will have a one liner (including a one liner config) instead of mapping N attributes in multiple situations, ok, but I'll consider to define some sort of simpler Mapper interface and put the tool behind it without leaking its details for application and domain layers.

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

#65

Post by f8o »

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.

A simple set of dtos in the application layer, defined around their respective application services (use cases if you will) is ok. Required for most bounded contexts/microservices. You properly organize application and domain layers. It does not need to be verbose. The problem is when people define dtos on the http infrastructure, then similar dtos on the app layer, domain models (often with all attributes being public and behavior scattered elsewhere), then dtos for database schemas... AutoMapper looks useful in these scenarios, but it's the wrong solution for poor design.

While manual handling is required when you have proper domain models with controlled creation and change operations, these tools can be useful for other matters.

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

#66

Post by Serow225 »

jnsie wrote: post #58
functionstooge wrote: post #21

Earlier quoted context omitted.

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?

https://mappinggenerator.net , it's great

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

#67

Post by neonsunset »

kaba0 wrote: post #57
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…

> 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.

Sorry, this was meant to refer to simplicity and focus of Go at solving problems it was designed to solve. Not that it doesn’t suffer from its own kind of boilerplate hell (the verbosity you mention), but it does not take away its upsides.

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

#68

Post by barking_biscuit »

orra wrote: post #7
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've used Automapper a few times, in Enterprise software which takes separate layers to a dogmatic extreme. Automapper always felt like a code smell: if the layers are so trivially mappable, should they really be different layers? Alternatively, isn't automapping a violation of the philosophy of separation of layers? All that said, given these mappers exist, the fact this Mapperly does ahead of time code generation i…

After the number of times I've seen AutoMapper absolutely abused and had to track down some really head-scratching bugs introduced by it, I've come to the conclusion that I'd rather just eat the pain of writing the mappings by hand.

And after the number of times I've started a job and asked about something that looked arcane, odd, and difficult to work with and gotten the reply "well we used to have this code generation tool", I've come to the conclusion that I don't wish to rely on code generation tools either because the incentives to build code generation tools and the incentives to maintain them seem to be severely misaligned such that building on a foundation of code generation tools seems to be equivalent to building on a foundation of quicksand.

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

#69

Post by barking_biscuit »

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.

Thank you. Now please ban it from planet earth.

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

#70

Post by grandpoobah »

hateful wrote: post #50
counttheforks wrote: post #19

Earlier quoted context omitted.

In webapps it's often very useful to accept a subset of a domain entity as an APIs request body, or to return it as a response body. 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 d…

Agreed. If you've come along the journey of first using the json attributes on your Domain objects to try and define your return but then get stuck the first time you have another API call returning a different subset of fields. It all clicked for me when I read somewhere: "The best way to define a data structure is a class, that's what they are". So now you can create Response and Request versions of your classes an…

All those KLOCs! Such productivity!
Post reply on HN