I'm beginning a new project (not corporate) and I'm curious as to what modern-day outstanding architecture looks like.
I'm now preparing to use:
Verifying the flow (please correct me if I'm wrong): The process starts with Controller calling ApplicationService, which calls a BusinessLayer, which calls DAL with UnitWork/Repository, which executes queries over EF or Dapper (is it correct to query Dapper from a specific method at Repository? ), and the result is then automatically mapped to a DTO and
As I said, the site is designed to get a lot of traffic, hence the issue is performance. Which of the aforementioned things could impact performance in this situation? Or does this combo reveal more? Should I stop using the EF and stick with Dapper only? I'm concerned that the traffic may cause the service layer to perform worse.
Finally, I'm not sure whether this design is just bad or superfluous.
That's a lot of questions, but the main goal is to identify an excellent solution for a medium-sized website that isn't "over architected."
Please pardon the English.
Since there are several alternative configurations, they may all be successful, your question is pretty arbitrary. However, I can offer you some suggestions.
It may be a little tricky to combine EF and Dapper. Theoretically, Dapper should allow you to get items and then
to the them
and make updates. But in my experience, that often fails. We first used EF, gradually switched to Dapper for quick querying, and I had assumed we could keep using EF for updates and inserts, but I ended up building my own insert/update tracking (quite simple), so we're gradually ceasing to use EF.
In retrospect, I advise choosing one and sticking with it. Under.NET 4.5, EF ought to run quickly. The pure Dapper path isn't horrible to pursue, although it's not as quick as Dapper.
Other technologies to think about: