Need clarification on AutoMapper usage

I'm having a bit of a moral dilemma, as to if we are using automapper if the right way and if our architecture is valid. I'm a relatively new developer but this just feels wrong to me. My colleague is a big fan of automapper (understandably so it rocks) but my issue is that we are using it just for the sake of it and trying to shoe horn in a pattern just because "That's how it's done". Basically we are building a web extension to an internal app that has a api and a nasty Sql database. We have created a number of sql views to pull the data we need for each screen. The views are then called using linq2sql and a repository pattern which then passes data to a service layer that automaps the data pretty much like for like to produce the Viewmodel objects to pass to the view. My issue is that do we really need autmapper here surely our data is already at a stag开发者_C百科e where we can view.. Also one argument for this is to give us control using view model metadata but surely this could be done with buddy classes on the linq2sql entities?

Am I missing something or does this seem unessential complex? Also I've been looking to use teleriks controls for the grid but with automapper standing in between my data and the output I'm unsure of hom to deal with this?

Thanks for any input ;)

I've built a moderate size ASP.NET MVC web application that sounds like its architecture was very similar to what you describe. We found that exposing our LINQ to SQL objects directly as view models to our views created a lot of friction in the project, since many of our views either composited multiple LINQ to SQL objects or relied on only a subset of a LINQ to SQL object's data.

Late in the project we started using AutoMapper to map LINQ to SQL objects to view models (and back) and it definitely allowed our system to be much more flexible. So I would recommend it.