Look at my mapping code…

Mapper.CreateMap() .ForMember(d => d.Tags, opt => opt.MapFrom(d => d.Tags.Aggregate(“”, (total, tag) => total + (tag.Name + “, “)).Trim(‘ ‘,’,')));
Mapper.CreateMap() .ForMember(d => d.Competition, opt => opt.Ignore()) .ForMember(d => d.Tags, opt => opt.MapFrom(d => d.Tags.Split(‘,’).Select(name => new Tag() { Name = name.Trim() })));

gist: https://gist.github.com/3650672

See, a design is submitted to a competition, so the competition already exists. If I allow
AutoMapper to map the competition property, EF would try to insert a new Competition,
so I have to ignore it and only set the foreign key. Of course, I have validation on the
DTO and on my Entity.

Is there anything wrong with this approach?

For now I’ve refactored that conversion process out into a method in the entity’s controller which also validates the EditModel. Not sure if this is a great idea, but I need to do validation that can’t be expressed in data annotations and this ensures only valid EditModels ever even become entities.

If I’m correct though, and I might not be, what Jimmy was talking about is a pattern that is very similar to what CodeCameServer uses, which involves the  MVCContrib.CommandProcessor.     

I’m still digging through the details, but generally it looks like all updates are done via calls to a rules engine. You give it a message object, and the rules engine can tell from the message object’s type which command it needs to run.

Setting up the rules engine involves creating custom classes that define the command, a class to define the rules to apply, classes for any custom rules, and a class that defines the actual message that will be passed around…. an outright obscene number of classes actually. 

It seems to be overkill times about a million, and I cannot justify this level of complexity in an app the size of CodeCampeServer. It would seem like a simple transaction script design  pattern would probably have done just fine, and been a lot smaller and easier to maintain. Maybe a rules engine like this makes sense given different requirements, or at a much larger scale (though I’d have to see details to agree).

Still though, the general idea is that the domain would expose very narrowly defined operations/commands for any writes to the DB. When you called those operations/command, you would not be passing in whole entity objects as parameters. Instead, you would pass in objects that are designed specifically for the operation/command being invoked, and back-end domain would then make or modify the appropriate entity objects.  

The command message pattern makes the assumption that only the back-end domain will instantiate or modify the real entities. The front end can read them, but would never change one.

This is not the dominant pattern used in asp.net MVC, at least not that I’ve seen. Many MVC apps use  entity objects as both input and output to the back-end; and this is especially true when using EF code-first or POCOs. Most of the books, code samples, templates, and scaffolders also use the back-end entity types bidirectionally; even when view models are being used as intermediaries.