Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

71%
+3 −0
Q&A What are the disadvantages of using auto mapper libraries?

It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exception...

posted 3y ago by jmathew‭  ·  edited 3y ago by jmathew‭

Answer
#3: Post edited by user avatar jmathew‭ · 2022-02-02T02:57:00Z (almost 3 years ago)
  • * It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exceptional cases are neat, but a regular property assignment is more readable, requires zero extra knowledge and in many cases, isnt that much more lines of code. Especially if your input and output objects have few properties to begin with.
  • * Readability can be subjective, but I'll define it here as "the ratio of code that is boilerplate versus code that does something interesting". Because of all the lambdas and custom functions that re-implement existing C# syntax, AutoMapper configurations are noisy.
  • ```csharp
  • // Conditional assignment in AutoMapper.
  • var configuration = new MapperConfiguration(cfg => {
  • cfg.CreateMap<Foo,Bar>()
  • .ForMember(dest => dest.baz, opt => opt.Condition(src => (src.baz >= 0)));
  • });
  • ```
  • ```csharp
  • // Same thing in a function.
  • public Bar FooToBar(Foo foo) {
  • // So many boring but readable bar.baz = foo.baz type statements.
  • bar.baz = (foo.baz > 0) ? foo.baz : 0;
  • }
  • ```
  • * I have to teach auto mapper. This isn't really a huge issue for some teams but auto mapper solves such a narrow problem that I feel this is worth considering. There is a learning cost to every tool added in the chain. When teaching people who are new to APIs in C#, auto mapper is more confusing than a transformation function. For many things a dev can already do with a for loop and a dream, they will have to search the AutoMapper way to do it. As an example, I cannot off the top of my head think how to have an input object with one array of data become two separate arrays in the output. I'm sure it's possible, but it requires extra thought. Further, those things they learn about AutoMapper don't extend to any other areas of a typical API project. Ironically (tragically?), the best way to learn AutoMapper, is to write manual transformations, get annoyed, then use AutoMapper.
  • * Debugging why a model is coming out different than expected is not straight forward. There's not only the map function I'm looking at but any global mapping configurations. I'm not confident about the output until I actually execute the code.
  • * It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exceptional cases are neat, but a regular property assignment is more readable, requires zero extra knowledge and in many cases, isnt that much more lines of code. Especially if your input and output objects have few properties to begin with.
  • * Readability can be subjective, but I'll define it here as "the ratio of code that is boilerplate versus code that does something interesting". Because of all the lambdas and custom functions that re-implement existing C# syntax, AutoMapper configurations are noisy.
  • ```csharp
  • // Conditional assignment in AutoMapper.
  • var configuration = new MapperConfiguration(cfg => {
  • cfg.CreateMap<Foo,Bar>()
  • .ForMember(dest => dest.baz, opt => opt.Condition(src => (src.baz >= 0)));
  • });
  • ```
  • ```csharp
  • // Same thing in a function.
  • public Bar FooToBar(Foo foo) {
  • // So many boring but readable bar.baz = foo.baz type statements.
  • bar.baz = (foo.baz >= 0) ? foo.baz : 0;
  • }
  • ```
  • * I have to teach auto mapper. This isn't really a huge issue for some teams but auto mapper solves such a narrow problem that I feel this is worth considering. There is a learning cost to every tool added in the chain. When teaching people who are new to APIs in C#, auto mapper is more confusing than a transformation function. For many things a dev can already do with a for loop and a dream, they will have to search the AutoMapper way to do it. As an example, I cannot off the top of my head think how to have an input object with one array of data become two separate arrays in the output. I'm sure it's possible, but it requires extra thought. Further, those things they learn about AutoMapper don't extend to any other areas of a typical API project. Ironically (tragically?), the best way to learn AutoMapper, is to write manual transformations, get annoyed, then use AutoMapper.
  • * Debugging why a model is coming out different than expected is not straight forward. There's not only the map function I'm looking at but any global mapping configurations. I'm not confident about the output until I actually execute the code.
#2: Post edited by user avatar jmathew‭ · 2022-02-02T02:54:11Z (almost 3 years ago)
  • * It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exceptional cases are neat, but a regular property assignment is more readable, requires zero extra knowledge and in many cases, isnt that much more lines of code. Especially if your input and output objects have few properties to begin with.
  • * Readability can be subjective, but I'll define it here as "the ratio of code that is boilerplate versus code that does something interesting". Because of all the lambdas and custom functions that re-implement existing C# syntax, AutoMapper configurations are noisy.
  • ```csharp
  • // Conditional assignment in AutoMapper.
  • var configuration = new MapperConfiguration(cfg => {
  • cfg.CreateMap<Foo,Bar>()
  • .ForMember(dest => dest.baz, opt => opt.Condition(src => (src.baz >= 0)));
  • });
  • ```
  • ```csharp
  • // Same thing in a function.
  • public FooToBar(Foo foo) {
  • // So many boring but readable bar.baz = foo.baz type statements.
  • bar.baz = (foo.baz > 0) ? foo.baz : 0;
  • }
  • ```
  • * I have to teach auto mapper. This isn't really a huge issue for some teams but auto mapper solves such a narrow problem that I feel this is worth considering. There is a learning cost to every tool added in the chain. When teaching people who are new to APIs in C#, auto mapper is more confusing than a transformation function. For many things a dev can already do with a for loop and a dream, they will have to search the AutoMapper way to do it. As an example, I cannot off the top of my head think how to have an input object with one array of data become two separate arrays in the output. I'm sure it's possible, but it requires extra thought. Further, those things they learn about AutoMapper don't extend to any other areas of a typical API project. Ironically (tragically?), the best way to learn AutoMapper, is to write manual transformations, get annoyed, then use AutoMapper.
  • * Debugging why a model is coming out different than expected is not straight forward. There's not only the map function I'm looking at but any global mapping configurations. I'm not confident about the output until I actually execute the code.
  • * It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exceptional cases are neat, but a regular property assignment is more readable, requires zero extra knowledge and in many cases, isnt that much more lines of code. Especially if your input and output objects have few properties to begin with.
  • * Readability can be subjective, but I'll define it here as "the ratio of code that is boilerplate versus code that does something interesting". Because of all the lambdas and custom functions that re-implement existing C# syntax, AutoMapper configurations are noisy.
  • ```csharp
  • // Conditional assignment in AutoMapper.
  • var configuration = new MapperConfiguration(cfg => {
  • cfg.CreateMap<Foo,Bar>()
  • .ForMember(dest => dest.baz, opt => opt.Condition(src => (src.baz >= 0)));
  • });
  • ```
  • ```csharp
  • // Same thing in a function.
  • public Bar FooToBar(Foo foo) {
  • // So many boring but readable bar.baz = foo.baz type statements.
  • bar.baz = (foo.baz > 0) ? foo.baz : 0;
  • }
  • ```
  • * I have to teach auto mapper. This isn't really a huge issue for some teams but auto mapper solves such a narrow problem that I feel this is worth considering. There is a learning cost to every tool added in the chain. When teaching people who are new to APIs in C#, auto mapper is more confusing than a transformation function. For many things a dev can already do with a for loop and a dream, they will have to search the AutoMapper way to do it. As an example, I cannot off the top of my head think how to have an input object with one array of data become two separate arrays in the output. I'm sure it's possible, but it requires extra thought. Further, those things they learn about AutoMapper don't extend to any other areas of a typical API project. Ironically (tragically?), the best way to learn AutoMapper, is to write manual transformations, get annoyed, then use AutoMapper.
  • * Debugging why a model is coming out different than expected is not straight forward. There's not only the map function I'm looking at but any global mapping configurations. I'm not confident about the output until I actually execute the code.
#1: Initial revision by user avatar jmathew‭ · 2022-02-02T02:53:21Z (almost 3 years ago)
* It's fairly obvious, but the greater the difference between the input object and the mapped output, the less valuable auto mapping becomes. The configuration and fluent syntax for the exceptional cases are neat, but a regular property assignment is more readable, requires zero extra knowledge and in many cases, isnt that much more lines of code. Especially if your input and output objects have few properties to begin with. 

* Readability can be subjective, but I'll define it here as "the ratio of code that is boilerplate versus code that does something interesting". Because of all the lambdas and custom functions that re-implement existing C# syntax, AutoMapper configurations are noisy.
```csharp
// Conditional assignment in AutoMapper.
var configuration = new MapperConfiguration(cfg => {
  cfg.CreateMap<Foo,Bar>()
    .ForMember(dest => dest.baz, opt => opt.Condition(src => (src.baz >= 0)));
});
```
```csharp
// Same thing in a function.
public FooToBar(Foo foo) {
  // So many boring but readable bar.baz = foo.baz type statements.
  bar.baz = (foo.baz > 0) ? foo.baz : 0; 
}
```

* I have to teach auto mapper. This isn't really a huge issue for some teams but auto mapper solves such a narrow problem that I feel this is worth considering. There is a learning cost to every tool added in the chain. When teaching people who are new to APIs in C#, auto mapper is more confusing than a transformation function. For many things a dev can already do with a for loop and a dream, they will have to search the AutoMapper way to do it. As an example, I cannot off the top of my head think how to have an input object with one array of data become two separate arrays in the output. I'm sure it's possible, but it requires extra thought. Further, those things they learn about AutoMapper don't extend to any other areas of a typical API project. Ironically (tragically?), the best way to learn AutoMapper, is to write manual transformations, get annoyed, then use AutoMapper.

* Debugging why a model is coming out different than expected is not straight forward. There's not only the map function I'm looking at but any global mapping configurations. I'm not confident about the output until I actually execute the code.