Links controller in MVC N-layer architecture
Do you need it?

From your question it seems that you don't and your Data Access Layer simply forward calls to underlying layer/framework and map properties back/forward.

Complexity (paired with flexibility) comes at a cost (as you see) and for unneeded complexity you pay this cost without any benefit. Drop unneeded complexity! EF abstracts many underlying DB access details and you may won't need to reintroduce Repository pattern. See also Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (read more for further details about when - IMO - Repository pattern is needed).

In a different context this kind of refactoring has even a name: Remove Middle Man. When a class (or an entire layer, in your case) is doing nothing but delegation/direct mapping then you should remove it entirely. 

You'll then have just your presentation DLL and your model DLL (with EF to hide/abstract database access and mapping). You may want to introduce another level of abstraction in your presentation layer (View Model) when underlying model is too different from model you present to your users (or when interaction model is very complex) but there you should follow common pattern/practice of your UI framework (MVC, MVP, MVVM, MVCVM or whatever else).

If, in your scenario, you start designing model layer then a code-first approach will let you design your domain classes adding little or nothing code for mapping (no ORM is perfect). With this path (requisites, domain model, presentation) I usually add View Model classes to fit presentation needing otherwise using Model classes directly). 

Repository Pattern, When?

I'd add a 3rd layer for Data Access only for these (not exhaustive list of) scenarios:


I need to map deeply different storage methods: relational database, XML file(s), file-system, NoSQL database.
I have to switch between different technologies: Entity Framework, LINQ to SQL, NHibernate.


For simpler scenarios (such as adding a Service layer) mediator, proxy and similars will (usually) do the job.

Note About Testing

With an ORM you (usually) have harder time to write tests because it's directly connected to underlying database. In this case to test extreme error conditions and/or to simulate network issues/speed can be harder. If you can't automate these tests elsewhere (for example with dedicated system tests instead of unit testing) you may want to introduce a different DbContext base class to be used for testing however details depends on ORM you're using, designing approach you selected and specific tests you need to perform.