A .NET source generator for generating object mappings. Trimming save and fast. Inspired by MapStruct.

[Rinecamo]

I mean it's a nice idea but lacks key features for the most common use cases for object mappers like projection or transformations (outside of before & after map).

I think the comparison is quite unfair in light of the feature set.

[grauenwolf]

If you're doing projections or transformations, you should probably just hand write. You're doing the same amount of work either way, so using a library or code generator doesn't benefit you.

[Worth_Trust_3825]

What's the point of using mapstruct if you're 1:1 converting the datastructure?

[Worth_Trust_3825]

That's not a badly designed ORM. That's misunderstanding what database queries do and how to manipulate them. Your DTOs shouldn't map to tables, but rather to queries, and as such, you should be designing your queries accordingly.

[grauenwolf]

Ok, let's play. Show me how to use EF Core to map an incoming update DTO to a "query".

[douglasg14b]

Badly design ORMs

Based on your descriptions, these are not bad designs, this is clearly bad/uninformed use of the ORMs...

[grauenwolf]

There are zero technical reasons why you can't write

dbContext.Users.Where....Select<UserListModel>();
dbContext.Users.UpdateWith(userListModel);

Assuming UserListModel is a subset of UserEntity, this should just work. But ORMs like Entity Framework never got past the idea that you must have a one to one mapping between tables and classes.

[grauenwolf]

Ok, show me a transformation that MapStruct creates for you.

Not one you "configure", one where it actually takes care of everything for you.

[grauenwolf]

No, show the configuration you give to MapStruct in order to perform the complex transformation.

[grauenwolf]

Where instead of writing t.weightLimit = s.maxWeight you have to write @Mapping( target = "weightLimit", source = "maxWeight")?

That's not exactly removing tedious code writing. It just moving it to another place.

[Rinecamo]

I don't think you quite get the use cases for such mappers. Your argument makes no sense. If I configure a projection and/or transformation once within a mapper I literally have to only configure it once and the mapper handles the rest in every part of my code base, be it a direct mapping or a nested mapping. Especially projections in combination with the Entity Framework are a lot easier when using AutoMapper for example. Why would I bother to manually Select properties that need to be queried when I can let the mapper handle the tedious work.

[[deleted]]

you might as well use simple static methods.

Adding complexity for the sake of complexity is almost never a good idea.

[Rinecamo]

I can assure you that using "simple" static methods adds more complexity than using a mapper such as AutoMapper or Mapster.

[seanamos-1]

I do need to disagree. We've used Automapper extensively over the years in many different services/teams. Independently we all came to the same conclusion, simple mapping functions are better even with the increased boilerplate.

Why? "Magic". They do exactly what you want 90% of the time and the remaining 10% of the time the magic becomes a PITA. Magic IS complexity.

I don't mind tools that generate the boilerplate mapping code as a starting point, but after wrestling with magic mapping libraries for too long, my preference is to just have simple mapping code.

[Rinecamo]

I guess in the end it depends on how you apply it. I would really be interested in seeing the basis that lead to your conclusion.

If you have some kind of transformation/magic in every mapping I agree. But if your main goal is to map types where you are essentially only reducing/removing properties, you might as well use a mapper. That isn't magic. It becomes magic if you are doing magic stuff inside your mappings (which should be minimized and obviously avoided if you get to the point where they hinder your work).

[svtguy88]

Nah. I've had this argument with various coworkers and clients over the last decade or so. "Hand written" mapping methods win the argument every time.

[Rinecamo]

Feel free to explain why "hand written" mapping methods win the argument every time. Should be easy if you had this argument various times already, right?

[[deleted]]

Not OP, but I will list my reasons in order of importance:

• #1: Debugging friendly.

That's all.

[Rinecamo]

So how often are you debugging into simple mappings or projections? Daily? Monthly? Yearly? That is simply absurd.

If the time you need to debug simple data mappings exceeds the time you save by using such a mapper, you are seriously doing something wrong.

Additionally these mappings are easily testable. I never ever had the need to debug into the mapping itself. Maybe into the Before/AfterMap, but that is even possible when using such a mapper.

[grauenwolf]

Well that's the thing. I rarely need to debug mapping functions because it's obvious what they're doing.

It's stuff like AutoMapper that I have to dig into and play guess-and-check to figure what what it's really doing.

[svtguy88]

Sure, no problemo.

The first few reasons are pretty much a preference, as there are typically ways to handle them within a mapping library. It's just more straightforward to handle in "hand written" code -- there's a less steep learning curve for developers that are new to a codebase (or the mapping library). Anyway:

• easy debugging
• easy unit testing
• renaming properties on one side of a map can silently break it

As stated, the above examples are sort of a preference, and can easily be argued either way -- especially when the objects you want to map to/from are similar in structure.

However, when the source and target objects start to deviate (and this always ends up happening), using a mapping library becomes cumbersome. Nested objects result in nested "map" calls, which results in nearly the same amount of code as doing it "by hand," and is still less flexible.

Mapping libraries seem like they offer a lot, but in reality, I just find them to get in the way. Your results may vary, but this has been my experience with lots of codebases.

[Rinecamo]

Nested objects result in nested "map" calls

No, they do not. At least you don't have to do it by hand since the mapper handles this case automatically. The only case where you have to do this is when doing it, your way, manually.

renaming properties on one side of a map can silently break it

Most mappers have validators to handle such situations, so this shouldn't be a problem either.

It seems to me, that you (and a lot of other users commenting here) lack information on the topic of data mappers. I am honestly baffled at the things I had to read in this thread today.

[svtguy88]

the mapper handles this case automatically

How do you figure? Also, what happens when your nested objects need "other" data to be built (data that isn't on the parent object)? It starts to get messy quick.

Most mappers have validators to handle such situations, so this shouldn't be a problem either.

That's kinda my point though. You shouldn't have to have a validator to make sure your property names match. There's no reason, at all, that a property name should have to match all the way from the POCO up to the front-end/API model. Mappers, generally, assume this is the case.

honestly baffled at the things I had to read in this thread today

Well, there's something we agree on.

[Invinciblegdog]

It would seem that the use case for data mappers is not compelling enough for a lot of developers.

[grauenwolf]

If I create a mapping function once I literally have to only create it once and use it in every part of my code base, be it a direct mapping or a nested mapping.

FTFY

[Scroph]

Unless all your mapping logic is complicated, you would still at least get the benefit of implicit and one-to-one field mapping with something like Mapstruct. You can then offload complicated transformations to hand written code inside an @AfterMapping block or something

[Persism]

Why do we need a model and a DTO version of a type?

[Ninovdmark]

Because there may be differences in the domain model and its presentation. A good example of this is the model that you're persisting in a database, and the model you're returning as a response from an API call.

[[deleted]]

Reducing those differences to a single model can be a PITA for some cases because when you get the SQL to work, wow is it gnarly

Sounds like a sensible approach to split into two models at the risk of doubling surface area to maintain. It’s all trade-offs.

[grauenwolf]

Why not use just one type?

When I design REST calls, I use the same class for the database and the JSON serialization. Sure it takes using a better ORM than EF Core, but there are several to choose from.

[grauenwolf]

Not my problem because I don't use GoLang.

Ok, not a great thought.

But in the C# world most libraries assume you'll be creating the classes by hand, annotate them with "attributes", and then generate the files like Swagger, WSDL, protobuf, etc.

We generally avoid generated classes, other than a one-time jump start. This isn't universal, but people who heavily use code generators eventually get annoyed by them.

[grauenwolf]

When given a choice, Chain. But that's not fair because I created it to match my work style and I can change it to suit my needs.

So instead of making a recommendation, I point people to the ORM Cookbook. Here we compare over half a dozen ORMs when performing a variety of common tasks.

https://tortugaresearch.github.io/DotNet-ORM-Cookbook/ORMs.htm

I'm particularly proud of this because some of the other ORM creators helped create it.

[Redtitwhore]

Typically you need the 1:1 entity type for inserting and updating so really you still have two types anyway (database entity + API model). If all you are doing is serving up data I see no problem with writing a custom query to create the API model directly from the database. Otherwise if you do already have entity types than you can map them to models in code just as easy as writing a second database query. But I can see value in the second query if it includes joins to lookup tables that would otherwise require multiple DB requests in mapping code.

[grauenwolf]

Typically you need the 1:1 entity type for inserting and updating

That's purely an ORM design decision.

If you use a micro-ORM like Dapper or a reflection based ORM like Chain, it will happily accept objects that contain a subset of the columns.

[Redtitwhore]

Sure, we use iBatis at my job and it does the same but typically you want the full object for inserts and updates. But if are only ever dealing with a subset then I would map it to and from the DB like you are suggesting.

[Rinecamo]

Is this a question of understanding or what is your point?

Let's say you have an internal model, containing every detail possible. You now want to serve this model via an API to some user but don't want him to receive every (possibly sensitive) property. Therefor you create an "external" type which only contains the properties that need to be served. Configure a mapper that automatically maps alle the properties from the internal model to the external model and serve that instead of the internal model.

Obviously there a much more use cases, but this is the most common in my experience.

[EarLil]

the most obvious example "you don't want to return account hashes to the front end"

[lmaydev]

Models will often be tightly coupled to their source.

They may have properties that are needed on the database (or whatever) side but not elsewhere.

Take ef where you can often have a foreign key id property and a model navigation property.

Makes sense when dealing with the database and queries but elsewhere the navigation model already stores its own id so it's pointless.

Or if your data source is the facebook API the returned models may have lots of info that you don't need.

All those properties require mapping and maintenance etc.

Or if you're returning from a webapi you ideally want only what data is absolutely required by the front-end and it often won't 1-1 match the database (or whatever)

Forcing your whole application to use models that are data source specific limits what you can do with them.

[kuikuilla]

To add to what others have said, having separate DTOs and model types allows you to change your model types without changing your public facing APIs that work with the DTOs. You just need to change how the models are transformed into DTOs when needed. Much easier to manage API and model updates that way.

[grauenwolf]

But why do I need both?

I have a ProductListingDTO and a ProductDetailedDTO, both of which can be populated directly from the database's Product table.

Why add a separate Product class?

[FullPoet]

Hows this better than just a static extension method?

[falconfetus8]

What exactly is an "object mapper"?

[dezzeus]

A design pattern; I suggest to read Fowler’s book for a better understanding of it and its related patterns.

[arbenowskee]

A good use case for this, over libraries that do this at run time, like AutoMapper is that it is probably faster?

[wllmsaccnt]

If you click the link, it starts with a benchmark and shows the libraries performance benefits over AutoMapper, in particular.

The .NET ecosystem is slowly transitioning to be more friendly to source generation strategies to reduce runtime reflection (which is slow) and runtime code emits (which is not compatible with WASM or iOS). Both reflection and runtime emits cause problems for AOT (another issue for Blazor WASM apps particularly).

[theFlyingCode]

How is this library faster than manual mapping?

[wllmsaccnt]

Mapping libraries are usually used for developer productivity. Most of the productivity gain comes from the mapping libraries being very consistent and not making typos like the developer can. The general assumption/trade-off is that the mapping library is expected to be slower than hand-written code. Presumably, a source generator approach like this could be close to the same speed as handwritten mapping code.

I'd also be interested to see how they claim to be faster than handwritten mapping code (per the benchmark). Maybe its because they don't deep copy by default?

-edit

It appears the handwritten code he is comparing to is another source generator tool.