I'm starting a new project (non-corporative) and I want to know how would be a great architecture nowadays.
What I'm planning for now is to use:
Checking the flow (correct me if something is wrong): Controller calls ApplicationService, that calls a BusinessLayer, that calls DAL with UnitWork/Repository, that execute queries over EF or Dapper (is it correct to query Dapper from a specific method at Repository?), then the result is automatically mapped to a DTO and returned to Controller, that copy what's needed to a ViewModel and returns a View.
The problem here is performance, as I said, the site is planned to have high traffic. In this case, any of the items listed above could reduce performance? Or this combination leaks something more? Should I discard the EF, and use just Dapper? I'm afraid the service layer could reduce the performance because of the traffic.
And finally, I don't know if this architecture is unnecessary, or just poor.
That's a lot of questions, but the focus is to know a great and not "over architected" solution for a medium-sized web site.
Sorry for the English
Your question is fairly subjective as there are many possible configurations that can all work well. I can give you some recommendations though.
Mixing and matching EF with Dapper can be a bit of a minefield. In theory, you should be able to fetch objects with Dapper and then
Attach them to the
DbContext and update them. However, in my experience that often doesn't work. We started out with EF, then slowly moved to Dapper for fast querying and I figured we could continue to use EF for updates/inserts but I ended up rolling my own insert/update tracking (surprisingly easy) and thus we're slowly phasing out use of EF.
In hindsight, I would suggest picking one and sticking with it. EF should be pretty fast under .NET 4.5. Not as fast as Dapper though, so the pure Dapper route isn't a bad one to take.
Other technologies you could consider: