The Best .NET Mapper to Use in 2023
ฝัง
- เผยแพร่เมื่อ 5 ก.ย. 2024
- Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
Hello everybody I'm Nick and in this video I will compare all the .NET Object Mappers to see which one is the best and which one you should choose. I tested Automapper, AgileMapper, TinyMapper, Mapster, MappingGenerator, Mapperly and also manual mapping to see how they compare.
Give Mapperly a star on GitHub: github.com/rio...
Workshops: bit.ly/nickwor...
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasG...
Follow me on Twitter: bit.ly/ChapsasT...
Connect on LinkedIn: bit.ly/ChapsasL...
Keep coding merch: keepcoding.shop
#csharp #dotnet
Mapperly has the benefits of not hiding references behind reflection, build time errors, speed, etc. and simplicity if you want to remove it later (can just copy the generated code out and remove the mapper).
I honestly prefer to just have a static function in the class that takes in model and returns the transfer model or vice versa it’s faster, easier to debug, easier to understand for people not familiar with your mapper of choice and requires 0 extra dependencies. It’s also removes the temptation of doing conversions in the mapper function itself which are just horrific to debug when something you didn’t write isn’t behaving as you expect, because some “clever” conversion is being done hidden away in the mapper. Too many bad memories for me to ever use a mapper
I haven't used mappers. But I was thinking pretty much the same problems you listed.
But if you have your SpotifyAlbumDto and SpotifyAlbum, and each of them have some Convert() method from one the other, then you have strongly coupled them. They must not be able to live in separate projects because that would mean a circular dependency reference.
And if somebody would get tempted to put clever conversion in the mapper... they would also put it in this static Convert() method... no?
Which is exactly one of the key advantages of Mapperly. Since it is source generated, you can actually view and debug the generated code just like the code that you write manually.
@@paulkoopmans4620 If you are doing conversions you want strong coupling in most cases, you want it to break if you rename a function without changing the mapper, otherwise you risk the code breaking in production.
You COULD catch this with good unit test coverage, but that requires you to do the tests the right way as he said in the video, having the mapping being able to break silently can be very costly and time consuming.
I have had that happen which is why I stopped using automapper. Sure if your the only dev, or if its a small, very tight team, you probably avoid breaking it, but if the team grows, or if the project is big and have lived for a long time, like a decade or more, there will be ample opportunity to miss some dependency and suddenly a price is 0 at the wrong time. Tracking that down, especially if its some edge case can take hours or days eating up all time you save by not building those tight coupling methods, and at worst its also cost you money and or customers.
When used for ORM mapping from a database or from external json, I do use them since I will make sure to verify the data, I usually do not trust data from the database opr from external sources, even if I know I put it there because I cannot be sure that no one else made changes to that data.
@@paulkoopmans4620 They could put clever conversion logic in the converter, but not to the same extent you can with mappers. With mappers you get full DI dedicated to just mapping, I’ve seen people literally inject a DBContext into the mapper profiles and use it during the mapping, which is far far worse than anything you could do in a static function. You don’t have to strongly couple anything, you could use interfaces and separate objects to contain the conversion logic, allowing for all aspects to be decoupled pretty easily if you really wanted to (which I never have)
Thx for comparison. I prefer writing mapper as extension method (outside of domain). Simple and dependency free only when I have a lot of mapping I'm thinking of using mapper. Mapperly looks interesting.
Most of the time I prefer manual mapping. I developed an also fast but very simplistic mapping library called hypercubus mapping which is based on that (just need to finish the test cases to open source it). It keeps some useful concepts behind mapping: the ability to separate mapping concerns into another layer, creation of profiles, automatic enumerable types handling and the reusability of mapping rules. I also like to put its usage behind an interface owned by each application so that it can be easily changed as the project develops. So if time is short we can start using Mapster with naming conventions and then move to hand written code later with hypercubus or the even faster Mapperly
Greetings Nick. I use AutoMapper. Mapperly seems like a better choice.
AutoMapper reduced the amount of code in the project, but it also tends to get complicated as soon as you deviate from base implementations. I found myself adding an extension method in some cases to tidy up initialization. One example is where mapping requires two different source objects.
In my experience about 30% of the time you need custom configutations in the mapping. Excluding properties, converting comma separated values to List, creating nested objects from several DTO properties, etc.
So I would love to see a comparison between these mappers in how easy-to-use are they in custom configurations.
All that is supported by all mappers. The critical thing is performance and setup. You can use that knowledge to pick the one that works for you.
On that topic, for me an advantage of AutoMapper over Mapperly is fluent configuration part.
It's simpler to maintain, easier to read and more flexible in my opinion than attribute-based configuration which seems to be the only approach available for Mapperly as of now.
While I agree that you should not have a lot of logic in your mapping layer, small things like different naming, ignoring fields or mapping from nested objects will add up into ten-s of attributes for a single mapping and code starts to look unpleasant.
@@nickchapsas you did start by saying you would compare how easy they were to work with, and that's where this request comes in.
@@nickchapsas I love that you're very passionate about performance. Though I feel like most developers would be willing to sacrifice some performance for reduced development and maintenance costs. Everything is about circumstance of course, but at least for myself, I'm not concerned with the difference of microseconds if the benefit is more something more easily created and maintained ;)
I have to admit I've never seen the need for mappers in what I do, and try to use a single set of models whenever it is appropriate. (Shared libraries, linked file references, etc)
@@b33j4y Can't agree more.
Mapping makes absolutely sense when you have a rich domain model in your application core, however, in the "outer layers" you need simple objects (DTOs mainly).
My life has become so much simpler since I stopped using mappers and started hand-mapping everything. It got even easier when ChatGPT started hand-mapping everything for me.
Did you copy paste your class in the chatbox?
@@dputra Yeah. I give it two classes and ask it to write the mapping between them. Sometimes I give it a simple example if it's struggling
That sounds a LOT better. Mappers are supposed to reduce work or boilerplate but it makes it a lot harder to find what is referencing that code. Manual mapping and getting ChatGPT to do it for you sounds like a great approach.
My favorite mapper now is manual mapping written by ChatGPT 💯
Just make it write the tedious parts, then wire in the more complicated ones ourselves.
But tell your boss you used manual mapping
I’d love to see a breakdown of entity framework’s mapping functionality and its performance cost. Stuff like defining an entity to have a Boolean property to represent a column that’s char(1)
The Jimmy reference got me!
I'm missing the case where there are actual property naming differences between models, and at least some mapper configuration is required, which is the most common scenario in my projects.
Yep, I was thinking about the same. A mapper which just takes properties 1-to-1, yeah that's simple. On the other hand - why do we even do mapping? To decouple the domain from the UI for example. But then - the correctness of the mapping relies on the structure of the mapped classes to be in sync. So if you change/add a property in a mapped class, you need to do the same in the target class. How is that decoupling?
I have been using AutoMapper for a long time now. I think I started using it back in the days of the static API.
HOWEVER, I have reached a point where I am prepared to dump AutoMapper as the maintainers of the source do not write very good documentation to explain certain things and even have gone so far as to just outright delete a question they didn’t like, saying it should be answered on Stack Overflow instead, which is just dumb when I was asking them for clarification on a point in their documentation related to breaking changes they introduced in version 12 that are poorly explained. One thing I will say is that they have a great method you can call in your application startup when you are configuring your mapper. After you have registered all of your maps, you can call the AssetConfigurationIsValid method. This ensures you don’t have any properties added after the fact that can’t be mapped or are missed. Very good thing to have, especially in your development environment.
All that being said, I am going to be looking closely at Mapperly to see if I can swap out AutoMapper for it. I admit I have included some business logic in my mappings in some limited places. I am going to be reassessing that approach in the future.
Thank you for this. I've always created my own custom mapper but am going to implement Mapperly in my current project.
I used to write my own mappings but that got laborious quickly so I switched about 5 years ago to Automapper. I've always found it ok but my biggest frustration with it though is it doesn't tell you when it's not going to work, it'll build with mapping errors etc. Mapperly looks good so I'm going to take a look at that one now. Thanks for the video, very useful.
I see few issues based on my deep dive in that problem:
1. Performance difference of mapping of an array with 100 items of small entities vs just few objects with complicated structures. I saw tests where simpler objects got mapped faster by one, while more complicated by the other one.
2. Use of projections. EFCore, Mongo, CosmosDb all take advantage from that. If you use map functions shown here all those will have to first download everything and then map, and then filter! I see this issue so commonly misunderstood. People get the fastest mapper to suffer even more than before.
3. Functionality. I can feed arrays or dictionaries of my classes to AutoMapper directly and it will convert it properly in one call. Ability to provide context, transformation functions, etc. ability to restructure objects (source has deep nested structure converting to flat object), ability to lookup values in another collection, and so on.
You should publish this to a public repository so one can test ones own mapper with the same test to see if you're doing good or not ;)
A: if you want a codebase which is maintainable for >=2 years? Don’t use any mapper library.
B: if you want to show of, that you can map a Type Foo to a kinda similar looking Type Bar, in a VERY basic scenario, with one line of code: take a mapper library
I need more documentation about Mapperly! Using the mapper for generating new data types, fill a dashboard dto, etc.
I have never experienced a practical benefit long term from automatic mappers, personally. In theory it would be nice if everything was automated, because the Dto and Model objects normally start in sync. But in practice they eventually diverge to the point that you usually need extra metadata at some point to do the mapping(because the requirements of the Dto don't always match the model types), and at that point I don't see the benefit of using config features of the mapping library. My tendency would be to just start with something like Mapperly and if it breaks or won't work for the use case, it is probably time to swap that mapping method to a manually written one.
It's really funny how I made a research on mappers today and I come back home to this video notification.
I handle mapping myself but I needed to find a way to focus on implementing functionality and worry less about mapping object.
Thank you for this video Nick, it has cleared up a few gray areas and helped me to focus my research. I'll still take on your advice to handle mapping myself where need be. That is a safer bet.
I used to go with automapper but then change for mapster which is way faster .... did not know about mapperly, i'll give it a try .... Thanks for that great insight on mapping tools
Thank you for showing me Maperly. I never liked runtime mapping and I never found any source generated mapper the last time I looked few months ago. I'm definitely going to try it out.
Mapster supports code generation as well.
Hi Nick,
What about using auto mapper with projection (EF core queries projected directly to dtos)
I've deviated from using mappers since a while ago. I got used to just either implement a "ToX" method, or explicit/implicit operators whenever I need some kind of conversion.
I'm not a fan of explicit/implicit operators because they re not as obvious, but the ToX extension method is my mapping approach of choice too
I prefer the ToType and FromType approach, and now with static interface methods is even better
Thanks. I’ll try it. I mainly use mappers to hide the DTOs returned by web services or mapping something to a view model.
Using a mapper for a one to one relation is a given in my opinion. Sure it depends, but most often the benefit of the lack-of/easy code makes it worth it.
It's once things get a bit muddier that it becomes hard to figure out what to do:
- use mapper and set things before/after manually
- go full 'manual'
I can live with flattening in an mapper, but once i have to split something in arrays or do more object/array altering things get complicated beyond readability very quick.
Decided to try mapperly following this video. I've always tended to write my own mappers rather than using something like Automapper in the past so it is my first foray into automated mappers. Unfortunately, it doesn't look like it supports doing something like this from what I see on the website where you have a generic type within both the DTO and the model and want to define that at the point you are mapping:
public partial class MapperlyMapper
{
public partial Email Map(EmailDto sendEmailDto);
}
public class Email
{
public T Message {get; set;}
}
public class EmailDto
{
public T Message {get; set;}
}
I did not know about mapperly, I use manual mapping, gonna give it a try on my next prject, thanks for sharing!
Automapper is a good object structure validator. Using built in validate in unit tests so i am sure that external dto after nuget update is still good for my domain objects
Mapperly might work for very basic scenarios where you have an exact match of all the names and types. One step aside and everything gets much more complex. E.g. with AutoMapper you can easily provide custom mapping for any property. With Mapperly I'm not even sure if it's possible. E.g. in source I have CreatedAt as a string in "YYYYMMDD" format and in destination it must be DateTime.
Mappers are only really required with external or legacy databases or libraries. Aside from that it a good argument for consistent variable naming conventions across code or single developer code bases by developers who are OCD about naming. :-) (I am: I name the same objects consistently across a codebase so I can search and address and refactor cross-cutting concerns easily!)
Hei Nick, amazing video, very surprised to have another amazing alternative such as Mapperly.
I wanted to ask what do you think about having manual mappings in the constructor of each DTO with their corresponding Entity model?
I normally used both in some projects (using xtension methods and using ctors inside dtos without further troubles)
Thanks and keep coding!
Great video, extensively use automapper in the way you describe, view to viewmodel but definitely considering the move to mapperly because of the source generation.
Mapperly looks awesome, as performant as manual code without having to type much
Will be using that going forward, thanks Nick!
In our project we map manually between db => bl => api because the dto can look different or sometimes we have different dtos, penending if an object is in a list or a detailed view. Also mapping from bl => db we want to update an entity, not creating a new one. Those are som reasons why manual mapping is required in our case.
So, for a part of our application, we have to build domain objects using the results of many separate calls to an Api (this is because we work with network devices, and network devices refuse to give you all of the information on, say, an interface with just one command or Api request).
Do mappers support the use case of "I have these several different DTOs, and I need you to make a conglomerate domain object out of them, ignoring some fields and using others "?
This is mostly a rhetorical question, because of course not! A mapper doesn't know your domain. In order to do what I just described l, you have to pre-cook your domain into the DTOs by identifying only the properties in the JSON (or elements in the XML, blegh) beforehand, which is already, basically, building a mapper by exclusion!
I can, however, see mappers being useful for pulling objects out of a database, though. And the example of going from a domain to a view model (like you mentioned), is an obvious win.
For everything else though? I feel like a custom mapper is the right call pretty much any other time.
The Jimmy easter egg 🤣 nice one!
I enjoy manual mapping as preferably implicit conversion operators on the DTOs.
I absolutely hate implicit and explicit operators for mapping because they are not obvious. None of these objects should know how it can be mapped to another object so for me using them is a complete no-no. I prefer extension methods for mapping so something like "ToResponse" for example. It's way more obvious when used and way more debuggable.
Hey Nick, Thank you for the great content. You did a video earlier about Mapster and it's source generating feature which I remember it had better performance. Why didn't you include that in the Benchmarks also? 😁
I think one important aspect that I seek in a mapper is "Expression mapping" which I heavily use in DDD and Specification pattern and converting expressions between domain layers. And that is why I would stick with AutoMapper as it supports it very well.
As far as I know (correct me if I am wrong) the others don't support it.
Anyways, nice video!
There's one thing I really don't understand. On one hand, there's so much content (not only from you) about memory efficient programming, being aware of even small allocations.
But on the other hand, when it comes to object mapping, seemingly everything gets thrown out of the window and data duplication (in memory) doesn't seem to be an issue anymore. I really don't understand how this goes together.
Why is it even necessary to map objects in many cases? Wouldn't an interface with a *wrapper* (adapter) implementation be way more efficient? Why is this approach seemingly just not a thing?
Two biggest things are:
- You get immutability since you copy the data. This is important if you want to make a clear distinction when moving data between layers in your project
- You're not tied to any particular set of properties. Mapping between two models with identically named properties isn't the only use case for mapping. Very often that's not the case. Tying yourself to an interface only couples these layers more since every change, such as name change, needs to be reflected in both the interface (which can act as your DTO) and the origin class.
Interfaces don't really fit in here since they usually don't solve the problem mapping does.
I haven't used any mappers at all.
I suppose I would've liked it when I was making a bunch of ViewModel and DTO type things, and so would my colleagues... One of them got fed up enough they spent some time writing a basic templating tool to generate the Model, VM, mapping logic, and common stubs for him.
I recently had to deal with a very badly done API that does things in about 20 different ways, and includes AutoMapper as a dependency. Every single call had its own namespace, with its own copy of the request, response, and the errors, and often with subtle differences.
And the library for that API literally 'casted' objects by serializing to XML and then deserializing it too.
I think it was supposed to use AutoMapper to introduce some consistency, but it just seemingly didn't do that anywhere.
And I've never used a mapper before, so while I understand the utility, I don't really understand how I'm supposed to use it properly, and that's kind of the wrong thing to figure out on a strict deadline...
Do all other mappers besides automapper support throwing exception during initialization if some field is not mapped? That is one nice feature, which you dont have when you manually mapping (but you can obviously also do manually)
That was thorough ! So useful. Thanks.
for big system with high trafic => manual mapper inside model class.
for small -> medium system => automapper.
I would like to see a test scaling this test that Nick did. I think it would be nice to see how each of them behaves with a larger amount of data. Also, I think Mapster has other methods to improve its speed, like source generation.
For me, mapping in general is better having it a simple function as they usually are quite simple. I avoid mappers at all costs. However, mapperly looks like an actual real value proposition, I will take a look to it
My thought also, just the fact that it will have compile time error is the key feature.
I have used automapper before but after having been bitten by property deviation over time (the project evolved over almost 16 years), i started to avoid them, any time you save developing you are likely to loose once you need to start debugging, or worse, the code breaks in production costing real money and or customers.
But I will need to look into this Mapperly, it has the potential to make me reconsider :)
Nice. But I would rather prefer manual mapping. I mean the word "Manual" is relative in this context. You still have to do manual stuff when configuring properties in the case when you have different property names.
The best mapper is no (automatic) mapper. Make the implicit explicit, avoid unexpected behaviour, don't worry about configuring custom mapping rules. In general, automatic mappers are probably a nice choice for smaller code bases, but in real enterprise systems they often quickly run out of control, hide the transitions between layers, etc.
I wish you would add mapster source generator version also to this benchmark.
I used AutoMapper, I'm looking forward to using Mapster (source generator) and mapperly in the future projects, but it depends on the project itself, for example if it's dynamic or like a wcf clients with different environment versions.
In my opinion mappers are usually confusing when it comes to maintainability.
Great video!
Configuration validation is one of the most important features for me. AutoMapper knows it. I always create a unit test with configuration validation that helps me to identify issues like forgotten unmapped properties etc.
Do other mappers know configuration validation?
Mapster supports it too and Mappely is compile time so your code won't even compile if you've messed something up
"Jimmy Bogard did nothing wrong!" 🤣
Mapperly is new to me, and I was surprised by its results. I think it'll be my next mapping pet😎.
#recommendation I don’t think I’ve seen you cover telemetry (I’m thinking OTEL but telemetry in general is something worth talking about). Interested to know how you go about it, which libs/tools you like, etc.
Which is the best when you are mapping between entities to DTOs, where the shape of the object or the names of the fields change?
The more interesting mapping patterns are needing multiple source fields to map to one target fields and visa versa and needing multiple source objects to map to one target object and visa versa. I am not sure if I would like a mapper that could not be configured. I do like a code generating mapper.
Awesome video. Keep the good work up
I use a mapper for security and configuration. Also I need to make the mapping talk to my database (so if client searches using properties in the dto, that must be translated to the correct database fields).
I've been using automapper for like 15 years... never occurred to me that there would be something as easy (or easier) - that was quicker - ok - thanks.... mapperly was just added to my project !! (and good to know I use it correctly - ...
I’ve only used Automapper, but Mapperly seems to be interesting.
I disagree on the part of not mocking the mapper in your unit tests. We create a separate unit test class for testing the mapper profiles. IMO, this allows for cleaner tests and makes it very easy to catch any issues you might have with your mapper, instead of having to determine if the test failed because of an issue with the method or an issue with the mapper. And if you have multiple methods using the same map, you don't get multiple test failures. You just get one failure for the mapper test that is testing that particular map. I do agree with you on not putting complex logic into your mapper. We, unfortunately, have already gone down that path, and every time I see it, I cringe a little bit. Hopefully some day in the future we will get time to refactor that.
AgileMapper is great for me. Thanks to the creators
How can I get the benchmark code from this video. Yes, I'm a paid member. Thanks for all you do Nick!!
Benchmarkdotnet only does benchmarks sequentially (not in parallel). But I wonder which approach handles better under load. It would be nice to see this done with NBench w/ RunMode = RunMode.Throughput, this would run parallel.
I used to use Automapper but after having a few cases where it silently broke some conversions causing a lot of problems and taking a lot of time I stopped. Mapperly though sounds interesting, if you can hint it, like require all fields to be mapped or filled and similar so that you do not end up adding a field that it fails to map correctly.
Just checked, it does not seem to have any way to enforce that all target properties are mapped or that all source properties have a target, which means that a change in spelling can still break the mapping :(
I think mapperly uses ILGenerator, I have tried to create ILGenerator object mapper for performance important functions but it was hard to handle all cases. Mapperly looks promising for performance
so, what about automapper 'ProjectTo', for example, in Mapperly? I always use this when mapping Db model to Api model. How do others use it?
Don't think it supports it. But Mapster should.
I use Mapster in my own projects and in my job. Mapperly seems interesting though.
MAPSTER: I got quite a way down conversion before I discovered Mapster does not support target classes that use constructor injection :'( We had used Automapper ConstructUsingServiceLocator. Documentation is not great
I wish I saw this video 3 hours ago :D I had this exact question and your video came in just in time!! thanks :)
Mapster also has source generated version.
I’m less concerned with mapping speed and more concerned with things like is it type strict (nullable vs non nullable) or will it do some intelligent cast/conversion
GPT is my mapper of choice.
The problem I find with mappers is renaming a property on an external DTO, and then the 'magic mapping' breaks, because it isn't a 1to1 mapping anymore. Manual mapping solves this as there a direct references to the property
Mapperly is source generated so that wouldn't be a problem because there is no "magic mapping" that can break. It's all compile time.
@@nickchapsas It's magic at build time vs run time I think was his point. It's only going to map LastName to LastName and if you change one class to SurName it won't map anymore where your manual mapping will be refactored when you change the field/property name.
Using Mapperly: Can I map a property to another property executing my own custom method? (I did not find anything in Mapperly documentation)
Using automapper would be something like this:
CreateMap()
.ForMember(x => x.AgeTarget, opt => opt.MapFrom(src => CustomConvert(src.Age)));
CustomConvert(...) is my custom method.
I either use a source generator (self written) or a DB view if it is purely "data out".
I had to fix once a dozen automapper-mappers because people did not bother test them as "automapper just works", so I'm defintely in the only manual mapping camp. Further I have many protobuf "one of" that need mapping into an own discriminated union, and so far automatic mappers have failed very badly a that.
Mapperly doesn't seem to support EF projections, so that's a huge deal breaker for me. Using AglieMapper today, and happy with it, but it's a little worrying that neither AgileMapper nor Mapster (that I was planning to try after this video) has not been updated in over a year.
It totally does. Though using static class and not allowing reflection.
When I feel lazy about writing implicit operators for mapping, I use Mapster. 🙂
In Mapperly how do you do simple tweaking?
For example, imagine I have a boolean on the model, and a {"Yes", "No"} string on the viewmodel. This is very easy to do on AutoMapper. But where are the entry points on Mapperly to allow to do this and how to do it?
I disagree about mocking a mapper. If you have a simple method that's
1) Get from db
2) Map entity model to dto model
3) Return mapped model
By mocking that mapper you can assert the database entity by reference was correctly sent to the mapper, and your mocked mapped result was the exact same one returned from the function
If you use an actual mapper you have a gap in your tests, or have to assert every property. Not to mention the rule of a unit test shouldn't depend on third-parties
Thanks for the video. I switched from autoMapper to Mapster based on your other video. I have created a function that takes two generic classes, one is an Entity whiles the other is a Dto. I want to find out whether this is a good approach. NB: this seems to be a good approach for my project. Please help.
Mapster also supports custom configurations called Registers (implementing IRegister) which improves performance by not having it figure out where to map.
I would like to add that while I agree that mapping should be as simple as possible, it sometimes requires a more complicated setup. For example, in my API layer mapping configuration, I inject the HashIds Interface to scramble the ids sent out and unscramble the incoming ids.
Mapperly definitely looks great. How can a change in DTO be reflected using Mapperly, will it auto update the generated code while I re-build?
I just tried mapperly over mapster but I’m having issue with rich domain model. I think it works great with for an anemic domain model but when your entities have value objects and methods to update fields it becomes more a pain than a help. Maybe I’m missing something with mapperly but the docs are quite poor
I am relativly new to that mapping issue: what about explicit and implicit operators and their performance? Shouldn't be they mentioned as well here?
No because they are a terrible way to do object mapping. Even if they were the most performant way to do it, this they aren’t, they should never be used for this
Tbh i don't bother. All mappers are used for is shuffling deckchairs around in a viewmodel. Just stick the original object in there and ignore the unnecessary fields. I can see they could be useful if the resulting object was used a lot, passed around to more than 1 function afterwards or requires data manipulation. But nearly all the time its just take a dto and copy a subset to a vm to use in a template.
Not really, I use Automapper, and I use it with `ProjectTo` to convert the Map to an IQuerable which is great and very efficient.
I use it Instead of doing extra DB requests or use `Include` just to get few extra fields.
I've been wondering for a long time why I need this at all, my company wants me to use AutoMapper but I thank it's useless.
I would just simply map in the constructor or a method in the DTO:
public class MyDto
{
public MyDto(MyEntity entity) { /* ... */ }
public void ToEntity(MyEntity entity) { /* ... */ }
}
This also has the advantage that I can make all DTO properties readonly, which don't need to change and all nullable properties (nullable reference types) always have a correct value.
Mapperly of course takes a lot of typing out of my hands, but as soon as I need a little bit of logic (e.g. a sum), it probably fails? I would just write it myself, provided it doesn't get too much logic.
I've also seen a project where there was a very rudimentary mapping concept of their own: just two map methods in a class that was then injected - so manual mapping.
But even that I find unnecessarily complex, why the separation? Mapping, DTO and business logic are interdependent anyway, so why separate them?
I also always wonder with FluentValidation why it has to be so complicated.
Yes, validator classes are quite useful, but why does FluentValidation build its own method syntax? Why isn't there just a Validate method, where you then validate classically and use methods prepared by FluentValidation (e.g. validate email)?
@Nick: Do you have a video about writing your own mapper?
Which mapper is the best for adding business logic? /s
It’s got to go to mapster if it can map anonymous types without configuration
Hot take, I do not think it is always necessary to have DTOs, in fact I would go to the extreme and say, never. json or whatever format we use between the services should form the contract, and serializer/deserializer with custom converters (if necessary), form the mapping layer, DTO is not necessary, this strategy is not possible only when the data transfer format is binary
Been trying to use mapperly but kinda got stuck on the circular dependencies, even with their annotation, my case seems to be more complex with some methods using a custom mapping and others not :/
If I'm not supposed to make database calls in the mapper then how am I supposed to resolve lookups?
Let's say System A has a table of users with unique email addresses. System B has a list of users where the email address is unique, but there is a user ID column in the table which the API requires me to use to reference the desired user. I have to resolve the user by the email address. Where would this transformation logic go?
I wonder how Mapster Code Generation approach would have faired.
I personally prefer doing it myself. It's more code to write but that's a small price to pay.
Nick "You should not be mocking the mapper in the unit tests.", I'm like "OK I won't."