Data Encryption in Data Layer with ASP.NET Core Entity Framework

The way you are doing DI is wrong.

First, the connection string belongs in the data layer. Or in the web.config file.

The next abstraction you will be dealing with is the DbContext, not a connection string. Your repositories should not know about connection strings. Your business logic will not know about DbContext etc.

Your UI will have no idea and will not instantiate anything related to EF.

Concrete answers to your points:

1. Do not add abstractions, until you are very familiar with EF. It already adds good abstractions like UoW, queries, using POCOs etc.

2. For DI to work, you have a Composition Root which references all components needed. This might or might not be in the WebUI project. If it isn't, you should expect that it does not reference EF or any other data related tech.

3. Stop right here. Stop adding abstractions over abstractions. Start with direct and 'naive' architecture and develop it over time.

Abstractions are a tool to deal with complexity. Absence of complexity means no abstractions needed (yet).

Assuming you are using a single database for both, I would look at having the database and ORM layer behind a web service that both UIs can consume. That would allow you to put your business logic where it needs to be and decouple things so that the day you need a mobile interface or whatever else, you don't have to write another data access layer. Assuming you are using WCF on a windows stack, some of the native bindings should be as fast as you need them to be and designing for this environment forces some good habits in terms of data management.

Having the facility to put some logic on the service side also saves on having to write anything twice.

The downside is that updating your API affects all your clients, so you might want to have that well defined to start with and it does mean your desktop client and your web api client are tied in more closely to the application as a whole, but given that they are sharing a data store to start with, that is not necessarily a bad thing.