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
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...
Answer
#3: Post edited
- * 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
- * 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
* 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.