Last post Sep 20, 2014 04:16 PM by jammycakes
Sep 20, 2014 06:27 AM|Zaixu|LINK
Currently in a bit of a bind where i should put AutoMapper functionality, this is my current structure.
Id suppose it should be under Infrastructure where my IOC is, however that creates an reference to entities. But means that viewmodels cant exist in the presentation layer and should be moved down into entities.
It could also be setup in entities if the viewmodels are moved there.
Else i could put automapper in UI, but that is presentation and really should have no concern about the setup of maps.
Or i could let both presentation and business logic layer handle each their own mappings.
Id like peoples opinion on this, as i can see pros and cons for each but nothing really speaks being the right thing.
Sep 20, 2014 04:16 PM|jammycakes|LINK
I'd suggest that you just have one project for everything except your UI.
There is absolutely no need whatsoever to have separate projects for your different layers. It just adds friction and complicates matters without providing any benefits in the slightest. The reason why people do this is that they want to try to limit the
presentation layer to talking to the business layer, to limit the business layer to talking to the Repository layer, and to only allow the Repository layer to talk to your ORM. This in turn frequently leads to an antipattern that I call the Anaemic Business
Layer, where your business "logic" classes contain methods that do nothing but shuffle data unchanged from your presentation layer to your data layer. If one of your layers isn't doing anything, you should feel free to bypass it.
The solution structure I'd recommend in most cases would have just three projects, at least initially:
Secondly, if your view models have the exact same properties as your entities, and you're just shuffling data directly from one to another using AutoMapper, again, that's usually a mistake: it serves no purpose whatsoever and just adds complexity. It's better
to just include your entities themselves as properties of your ViewModel classes.
Keep things simple and don't add unnecessary complexities unless there is a genuine business need for them.