[RESOLVED] OOM - Automapper the way to go for CRUD and 2-way mappings?

[Krokonoster]

I've been trying to figure out AutoMapper over the weekend and (I guess it's just me) it just does not cut the mustard with two-way mappings.

Sure it's simple enough to flatten domain models into view models, but that's just one of the features I need from an OOM.

Can anyone perhaps post an example of a successful AutoMapper implementation with two-way mappings and CRUD operations (If it include dependency injection with Castle that would be grand!)
(CodeCampServer does it, but it's implementation is a bit confusing without proper documentation)

For time being I created my custom mapper (lot of code, and probably going to be slow, but I did not like the direction my mappings was going using AutoMapper)

[Krokonoster]

For example, the below Domain Models and ViewModel:

// Domain Models...
public class ProductCategory
{
    public int Id { get; set; }
    public string Name { get; set; }
}
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public DateTime CreateDate { get; set; }
    public int CategoryId { get; set; }
}

// View Model .....
public class ProductViewModel
{
    public ISharedDataService SharedDataService;
    public ProductViewModel(ISharedDataService sharedDataService)
    {
        SharedDataService = sharedDataService;
    }

    public int Id { get; set; }

    [DisplayName("Product Category")]
    [Required(ErrorMessage = "Please select a category this product.")]
    public int CategoryId { get; set; }

    [DisplayName("Product Name")]
    [Required(ErrorMessage = "Please enter a name for this product.")]
    public string Name { get; set; }

    // select list for displaying existing categories in dropdown list
    public SelectList ProductCategories
    {
        get { return new SelectList(SharedDataService.GetProductCategories(), "Id", "Name"); }
    }
}

[Pino]

I've usede the AutoMapper and ended up dropping support for it as it seems way over complicated and I much prefer having control over the mappings. I found exactly what you found in that I ended up writing more code for the AutoMapper. Whats convinced you to keep using it?

Why not extend the base class of your DAL to contain a ToViewModel() function or add the set-up in the constructor of the view model. It removes external lib's and keeps things simple.

[Krokonoster]

Glad to hear I'm not the only one having issues using Automapper.

Your solution is a practical one, but I do not want the DAL have any knowledge (or references) to the current front end, or vice versa

My current implementation is fine. Just a single line calling static methods converting viewmodels <=> domainmodels (basically what you are doing also).

Just worried about the cost of doing that. Still in the project's baby shoes and spent the whole evening writing my own "mappers" for what I have now. Also not sure how resource intensive it is compared to whatever AutoMapper use internally.

[Pino]

Because AutoMapper uses Reflection perfomance will always be lower than doing it your self. I'm using Subsonic for my DAL and really the DAL has no knowledge of the View. I cretae a Partial class to add the extra functionality.

namespace Lib.Data
{
    public partial class Product : Lib.Data.DAL.Product
    {
        public ProductModel ToDataModel()
        {
            var returnData = new ProductModel();

            returnData.Name = this.Name;

            return returnData;
        }
    }
}

Now that will work with SubSonic or Entity framework or ideally any ORM tool. I can now do the following in my service layer.

var curProduct = new Lib.Data.Product(); //Obv have the fetch one
//Return as data model

curProduct.ToDataModel();

Now, i'm open to reasons why this is good or bad and interested to share your thoughts.

[Krokonoster]

Thanks, you just cost me my whole afternoon/evening implementing that!
Great solution, thanks! (Nope, I'm not smart enough to argue with that. )