Tech learning

jQuery Datatable is one of the popular freely available grid for the developers. It works really great on the client side but there is always need to write a lot of codes on the server side for filtering and sorting for each individual entities. In this article, we would address this by creating a generic implementation of server code which can work on any entity without writing any further piece of code for filtering and sorting. Just by calling a generic extension method it would resolve sorting and filtering. The key points to achieve it are as follows: - Model binding and provider to transform client side request to strongly typed item on the server. - Once we get strongly typed items to read values, we can apply a dynamic approach to generate queries and filters through LINQ expression. - At final part, just consumption of created mechanism by creating endpoints for each entity. Also, we can easily select required columns through LINQ projection. Model Binding As per Da...

How many lines of codes we waste on mapping from one source to a destination like DataModel to ViewModel.  There are well-known Mappers available to do the same but nothing can come close in terms of performance by using manual mapping just that we need to write at too many places or takes a huge chunk of code lines in our main codes, may be under controllers, services or where ever you prefer projection in code. The idea is to develop a proper way to deal with mappings. Some time back I had written code for manual mapping under LINQ queries.  Manual model mapping - LINQ projection technique , this still works great. The idea is to create a cleaner solution as a whole new package for handling Mapping which can support general mappings between models and support of LINQ projection to select the limited number of rows as required. Primary objectives of the implementation. - A Data model to view model/DTO/or any other. - view model/DTO/or any other to a data mode...

There are various object mappers available like AutoMapper, TinyMapper, EmitMapper, ValueInjector and many more mappers. They all provide a flexible way to do the mappings from one object to another without much effort. When it comes to performance nothing can beat good old manual mappings. The downside is, it get mixed up under projection from LINQ queries. By mixing projection, we hard code the mapping between model, if again it needs to be mapped to some other place, then write that again. The ideal approach should be separating the mapping to some other place, it also takes care of SRP pattern and also our code manageability increase by keeping projection/mapping separately. The usage can be very simple. Here is expression technique to map one entity model to view model. public Expression<Func<SecurityUser, UserBasicInfo>> MapUserBasicInfo() { return (user) => new UserBasicInfo { FullName = user.Person.FirstName + " "...

In AutoMapper 4.2 version, static implementation is removed with instance approach. It could be a nightmare to migrate the codes to the newer version with instance approach. I will be putting up guide for migrating codes from the older version to instance approach if someone has used Profile based approach. Previous implementation (old implementation) Profile based implementation mapping public class UserProfileMapping : Profile { protected override void Configure() { Mapper.CreateMap<UserProfile, PreferenceViewModel>() .ForMember(vm => vm.UserId, m => m.MapFrom(profile => profile.Id)); } } Single class for registering all AutoMapper configuration public static class AutoMapperConfiguration { public static void Configure() { Mapper.Initialize(cfg => { cfg.AddProfile(new UserProfileMapping()); }); } } ...

We generally use these extension methods First/FirstOrDefault/Last/LastOrDefault/Single/SingleOrDefault with predicates like ctx=> ctx.Model.FirstOrDefault(item => item.Id == 1 ) Or ctx=> ctx.Model.Where(item => item.Id == 1 ).FirstOrDefault() What is the problem with these? FirstOrDefault or similar methods immediately loads all data at once. So, let's say we have fifty columns on table then all those columns data would be retrieved from DB and saved into memory. This link gives a fair idea of different function behavior.  https://msdn.microsoft.com/en-us/library/bb882641.aspx .  So, even if we require only one value from selected field it retrieves all values. What is the solution? The solution is pretty simple. Whenever we need selected items better to do projection before calling FirstOrDefault or similar methods. Ex: Selecting single item ctx.Model.Where(itm => itm.Id == 1) .Select(itm => itm.Name).FirstO...