What are non-ORM architectural patterns for ASP.NET MVC?

Question

SQL

Hello dear developers!
Tell me, please, what architectural design patterns for web applications (ASP.NET MVC 5), without the participation of ORM, can you pay attention to? Now I'm using a bundle that can be called " Repository + Onion ", and the project structure is as follows :

1. Domain -- domain model;
   
2. Data -- a layer referring to the Domain, which defines the classes of repositories (they contain methods for working with the database), their interfaces (not yet separated for design convenience), as well as "entities" whose properties match the attributes in the database tables;
   
3. Infrastructure -- refers to Domain and Data, and contains methods that interact with repository interfaces and cache query results from the latter;
   
4. Services -- a layer that refers to Domain, Data and Infrastructure, acts as a facade of infrastructure subsystems (interacting with the interfaces of the Infrastructure layer);
   
5. Util -- refers to Data, Infrastructure, Services and is responsible for resolving dependencies;
   
6. WebApp -- refers to Domain, Util, and Services -- an ASP.NET MVC 5 web application.
   

General requirements:

1. UoW doesn't fit;
   
2. no EntityFramework, NHibernate, etc., all SQL queries are written by hand;
   
3. you can use "micro-orm" Dapper;
   
4. maximum isolation of the layers from each other as much as possible;
   
5. using DI.
   

Many thanks and low bow to everyone who names at least one pattern or gives advice on the topic!

Answer 1

It is difficult to advise you on a pattern, because you basically said what your problem is . It is not clear for which architectural task you are choosing a pattern.
You have indicated that you are already using the Repository. If so, then everything should be fine with abstraction from the data acquisition layer - you can implement the repository the way you need, including SQL queries.
Even if you don't want the whole ORM, you may want to implement some of its functionality yourself for convenience. For example, you probably still want to have an Identity Map so that your objects (which your Repository implemented with manual SQL queries will return) were indeed objects, not records. Or even some Lazy Load.
In general, now there is a feeling that you are not solving a problem, but are trying to collect a record collection of patterns.