During all my work I've been working with ORM, WS, integration services, viewmodel and so on.

The common stuff in all these kind of work is that I had to make mappings and not always the available framework are enough to help in this mapping.

The question which I'm wondering is: is a consistent part of the development process dealing with mapping? It would be good to develop a tool for solving this kind of problems?


sqlClient.AddParameterWithValue("switch", SqlDbType.TinyInt, user.IDUser);
sqlClient.AddParameterWithValue("IDUtente", SqlDbType.Int, user.IDUser);


GetSQLParameter("@switch", SqlDbType.TinyInt, 1), _
GetSQLParameter("@IDUtente", SqlDbType.Int), _


MappingFramework.Mapper.CreateMap<DataRecordWrapper, User>()
    .ForMember(dest => dest.IDUser, opt => opt.MapFrom(src => src.GetInt("switch")))
    .ForMember(dest => dest.FirstName, opt => opt.MapFrom(src => src.GetString("IDUtente")))
  • You already mentioned Automapper as an available tool. Yes, moving data around and mapping it from one thing to another does consume a substantial amount of the average programmer's time and effort. Mar 20, 2014 at 16:09
  • @RobertHarvey: thanks. I will remove the reference to automap.. I didn't mean to advertize it.. Mar 20, 2014 at 16:14

1 Answer 1


It's about integration.

The vast majority of software exists simply to integrate systems together so that tools and data and various things can all interoperate to make larger more robust products. The amount of any industry that is inventing novel products rather than taking known products and combining them is terribly minuscule, this goes for the software industry as well. A large majority of what developers are doing is integrating separate systems to get multiple independent features/products to work together as a single cohesive product.

There are tools out there that have attempted to generalize this task so that you can utilize them to do all of your integration of separate systems and features; they're called ETL tools. They're far too generic for most of the work we do integrating systems, but some people use them to drive their entire product.

It's often simpler to create something purposebuilt for each little integration spot than to use a general approach to all integration because general approaches have to be far larger, more robust, and due to that more complex. Like I said, some people do use ETL tools to drive their entire product, but ETL tools are vastly more complex and tricky to use than writing a few lines of code purposebuilt for a given integration spot.

  • Why I cannot upvote your answer? Mar 21, 2014 at 8:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.