Data Accessor Design Pattern for C# application where most of business logic is in SQL Stored procedure?

Here are the details about our development environment:

• DevExpress 20.2.3 ( we are using DevExtreme )

• Microsoft Visual Studio Enterprise 2019 (Version 16.4.6)

• ASP.NET Core 3.1.0

• AspNetCore.Mvc 3.1.0.0

So, we are revamping/redesigning an ASP.NET Core Web Webapplication for uploading various business types of data for our clients. A lot of the processing business logic is already in the SQL stored procedures associated with the application. The diagram below should give you a general idea as to how the business data flow process works in the application:

Initially, the web user will upload Csv data Files containing business data. C# will convert said business data into a C# datatable. Since most of the business logic are in the SQL Stored procedures, the C# code Only deals with passing and retrieving C# DataTables from the SQL stored procedures.

There are many SQL stored procedures that are being invoked in order to process said business data. At present I just have Data Accessor class that will invoke said SQL stored procedures, and also gets back DataTables from the aforementioned SQL stored procedures.

However, the Data Accessor code is really big, inelegant & unsophisticated.(Lol, it's a file that is getting really big) Therefore, I'm wondering what kind of Data Accessor design patterns I should use.

I was thinking about the Repository pattern but I don't want to waste time Unnecessarily coding C# POCO objects corresponding to the various Business Data Types (i.e. Investors data, Redemptions data, Subscriptions Data, etc.) that the application takes.

Since the SQL Stored procedures do most of the business process logic, the C# code hardly does any processing of the business data. Therefore, it's kind of a waste to use the Repository pattern.

I'm wondering if I should use CQRS pattern.

• Could someone please give some suggestions as to which Data Accessor Design pattern should be used in this case?

• Also, could someone please provide details as to how I should go about using said design pattern for this particular case? Note: I'm Not really interested in using an ORM like Entity Framework or NHiberate because it takes time to integrate it into the application, but if someone has a strong argument for using the ORM then please feel free to tell me why and how it will will help here