rehansaeed.github.io
rehansaeed.github.io copied to clipboard
RehanSaeed
[Comment] A Simple and Fast Object Mapper
What an incredibly well done post! Than you! Ok, I have a question. Normally I presume that during testing, my IOC container or configuration will repoint my SQL Server connection to a more light-weight tool such as SQL CE or LocalDB. You implied that providing sample data, for testing purposes, to SQL CE or LocalDB is difficult in comparison with using EF Core in-memory. Why is that so?
What an incredibly well done post! Than you! Ok, I have a question. Normally I presume that during testing, my IOC container or configuration will repoint my SQL Server connection to a more light-weight tool such as SQL CE or LocalDB. You implied that providing sample data, for testing purposes, to SQL CE or LocalDB is difficult in comparison with using EF Core in-memory. Why is that so?
Perhaps I could have been clearer. There are a few extra problems when you have to deal with a real database, as opposed to an in-memory database:
- You have to have a real SQL Server provisioned. This may be simple if we're talking about a developer machine but what about when we run the tests in a CI server? Do you pay for a server just for functional tests?
- You need to create the database, database schema and the user needed to connect to the database. You also might need to think about migrating the database (See next item).
- You could drop the database and recreate it after each test but that would be dreadfully slow. Instead you should probably look at a tool like Respawn (Another great project by Jimmy Bogard) which clears the database instead making the test a lot quicker. The downside is that now you have to deal with migrations as I mention above.
Even after all this there are downsides. It will still be slower than an in-memory database, a lot more complicated and possibly more costly. On the upside, you have something that is a lot more real-world, so you may catch bugs that you wouldn't catch if you used an in-memory database.
This is great. I've been doing something very similar. What I would love to have is a VS extension or tool to autogenerate these mappings.
This is great. I've been doing something very similar. What I would love to have is a VS extension or tool to autogenerate these mappings.
That would be a nice extension!
Great article and great work achieving these performance gains! I'm curious, what motivated you to create a new mapper when AutoMapper is essentially the de facto standard in this area? Did you run into performance issues with AutoMapper or were you generally just looking for something more light weight?
Great article and great work achieving these performance gains! I'm curious, what motivated you to create a new mapper when AutoMapper is essentially the de facto standard in this area? Did you run into performance issues with AutoMapper or were you generally just looking for something more light weight?
I used to use Automapper and always found little annoyances with it. I believe the latest version is much improved though. In the end, I just thought, this is way over engineered, I just want to map some properties and I can do that by hand in 30 seconds. It'll be boring but it'll work, be dead simple and fast. I then started to write an interface and a few extension methods to help me write mapping code quicker which resulted in this blog post.
hi rehan how to resolve this problem when using boxed mapper and DI in my project? example :
public interface IPrepareProduct<TProduct, TProductDto>: IMapper<TProduct, TProductDto>
{
}
public class PrepareProduct : IPrepareProduct<Product, ProductDto>
{
public void Map(Product source, ProductDto destination)
{
destination.CreatedOn = source.CreatedOn;
destination.Description = source.Description;
destination.Name= source.Name;
destination.FromDate= source.FromDate;
destination.Id= source.Id;
destination.InStockCount= source.InStockCount;
destination.OldPrice= source.OldPrice;
destination.Price= source.Price;
destination.PreViewText= source.PreViewText;
destination.Published = source.Published;
destination.SKU= source.SKU;
destination.ToDate= source.ToDate;
}
}
/*******************************/
public interface IPreparePicture:IMapper<Picture,PictureDto>
{
}
public class PreparePicture : IMapper<Picture,PictureDto>
{
public void Map(Picture source, PictureDto destination)
{
destination.Alt = source.Alt;
destination.EntityId = source.EntityId;
destination.EntityName = source.EntityName;
destination.id = source.id;
destination.IsDefault = source.IsDefault;
destination.Order = source.Order;
destination.Title = source.Title;
destination.Url = source.Url;
}
}
how to ignore some property in your object mapper ?
how to ignore some property in your object mapper ?
Just don't write the line of code that does the mapping i.e.
destination.SomeProperty = source.SomeOtherProperty;
hi rehan how to resolve this problem when using boxed mapper and DI in my project? example :
public interface IPrepareProduct<TProduct, TProductDto>: IMapper<TProduct, TProductDto> { } public class PrepareProduct : IPrepareProduct<Product, ProductDto> { public void Map(Product source, ProductDto destination) { destination.CreatedOn = source.CreatedOn; destination.Description = source.Description; destination.Name= source.Name; destination.FromDate= source.FromDate; destination.Id= source.Id; destination.InStockCount= source.InStockCount; destination.OldPrice= source.OldPrice; destination.Price= source.Price; destination.PreViewText= source.PreViewText; destination.Published = source.Published; destination.SKU= source.SKU; destination.ToDate= source.ToDate; } } /*******************************/ public interface IPreparePicture:IMapper<Picture,PictureDto> { } public class PreparePicture : IMapper<Picture,PictureDto> { public void Map(Picture source, PictureDto destination) { destination.Alt = source.Alt; destination.EntityId = source.EntityId; destination.EntityName = source.EntityName; destination.id = source.id; destination.IsDefault = source.IsDefault; destination.Order = source.Order; destination.Title = source.Title; destination.Url = source.Url; } }
You have not outlined the problem. Also, please raise a GitHub issue to get better answers.
Hi Rehan,
fan of your work, as always.. In this case, I am looking for any advantages using this approach, over say, DTO Writer, which will auto-generate mappings:
https://marketplace.visualstudio.com/items?itemName=VitaliiIlchenko.DtoCreator
This creates static methods for ToModel and FromModel.
I admit to being a big fan of code generation.
Perhaps I am missing something, as I have only spent an hour or so looking at this?
Hi Rehan,
fan of your work, as always.. In this case, I am looking for any advantages using this approach, over say, DTO Writer, which will auto-generate mappings:
https://marketplace.visualstudio.com/items?itemName=VitaliiIlchenko.DtoCreator
This creates static methods for ToModel and FromModel.
I admit to being a big fan of code generation.
Perhaps I am missing something, as I have only spent an hour or so looking at this?
Hi David,
That's a really good question. This tool looks useful, I've not heard of it before but I've seen another one in the past. I've even thought about building my own once or twice. Questions I would have are:
- Does it help when you want to edit a DTO to generate code for new properties you've added, removed, renamed or where you have changed the type?
- Does it handle more complex objects that are not just POCO's? Things like immutable types where the only way to create the object is from the constructor.
- Does it handle nested POCO's? This is pretty common.
Overall, it might get you started quickly but I'm not sure that it will be flexible enough. Also, one thing that I've never understood is the time saving factor. It really doesn't take long to write a mapper, unless maybe you have lots to do.
Hi David,
That's a really good question. This tool looks useful, I've not heard of it before but I've seen another one in the past. I've even thought about building my own once or twice. Questions I would have are:
- Does it help when you want to edit a DTO to generate code for new properties you've added, removed, renamed or where you have changed the type?
- Does it handle more complex objects that are not just POCO's? Things like immutable types where the only way to create the object is from the constructor.
- Does it handle nested POCO's? This is pretty common.
Overall, it might get you started quickly but I'm not sure that it will be flexible enough. Also, one thing that I've never understood is the time saving factor. It really doesn't take long to write a mapper, unless maybe you have lots to do.
Rehan, actually a combination of DTO Writer and this would seem to match most needs:
https://github.com/cezarypiatek/MappingGenerator
Rehan, actually a combination of DTO Writer and this would seem to match most needs:
https://github.com/cezarypiatek/MappingGenerator
In my case, I very rarely only have a small number of classes to map, so generation saves a bit of time, and potentially errors when repetitively coding simple tasks.
For adding properties or something more complex than one-to-one mapping, I would probably just do that by hand. These tend to be the exceptions, rather than the rule, and it is not worth attempting to automate complex logic...
... unless someone else codes it for me ;-)
David
How to manage different property name of entity ?
Lets say I have an entity
public class person
{
public string name {get;set;}
}
public class personDTO
{
public string personName {get;set;}
}
A more extensive example mapping a simple object hierarchy would be really helpful.
How to manage different property name of entity ?
Lets say I have an entity
public class person { public string name {get;set;} } public class personDTO { public string personName {get;set;} }
Easy:
destination.Name = source.PersonName;
A more extensive example mapping a simple object hierarchy would be really helpful.
Here is a more extensive example:
https://github.com/Dotnet-Boxed/Framework/blob/master/README.md
The problem with manually writing mappers is that you also have to manually write tests for them.
That takes a lot of time. AutoMapper does it for us.
The problem with manually writing mappers is that you also have to manually write tests for them.
That takes a lot of time. AutoMapper does it for us.
I don't think that code takes very long to write. You still have to write a test if you use Automapper. Docs suggest this:
var config = AutoMapperConfiguration.Configure();
config.AssertConfigurationIsValid();
It checks that every single member has a destination type. It may not be the right one (since there are always exceptional cases), but it at least tests that every property is copied from source to destination.
There are pros and cons. Automapper still has it's uses.
I like the direction you went with this. We struggle back and forth with the same person points of automappers as you do. Mostly property references. I want to know what you consider different about your approach than manually mapping (I think you called this baseline)? Yes you are creating a mapping framework with the interface but you are still manually writing the mapping. I am not opposed to manually writing the mapping a because we do that now and it's the most performant, but isn't yours also manually mapping? How is your benchmark time slower?
I like the direction you went with this. We struggle back and forth with the same person points of automappers as you do. Mostly property references. I want to know what you consider different about your approach than manually mapping (I think you called this baseline)? Yes you are creating a mapping framework with the interface but you are still manually writing the mapping. I am not opposed to manually writing the mapping a because we do that now and it's the most performant, but isn't yours also manually mapping? How is your benchmark time slower?
It's really just a set of extension methods to make mapping easier and interfaces to standardise things so developers know what to expect. That's it. Just enough to make manually mapping more bearable and slightly faster to write.
The time is mostly a bit slower because we use an interface and we also use a different method of newing up instances of types as opposed to the new keyword.