-1

I've have an n-tier .NET 4.6 internal business application. It has a business logic layer class library project that references a data access layer class library project. It's designed to decouple the two so that, in theory, a different data access assembly could be swapped out without modifying the BLL.

But a new idea has just entered the picture. We want to use these projects to also support a public-facing website via a web service application. To help alleviate database server load (trying to avoid SQL Enterprise licensing), we had the idea, "what if we do some of our large read-only queries from a replicated database, while doing the less frequent inserts and updates to the master database?"

They will be identical databases so my DAL still works against both, but it simply connects to the single connection string its configuration file. I never planned on it choosing a data source at runtime so there could also be other ApplicationSettings, static variables, possibly issues with managing the life of the DALs Entity Framework DbContext lifetime... So it seems like what I really need is two parallel instances of that assembly. I could do that by creating two separate web service applications for each place, but could it be done within a single application? I have a feeling a total redesign with some kind of configuration DI is probably what is needed for this use case, but curious what the options are, if any, for running two parallel assembly instances/configurations.

Improve this question
3
  • could it be done within a single application? - based on description of your database layer project - No, it is not possible without code changes of how DbContext being instantiated and consumed.
    – Fabio
    Commented Jan 27, 2020 at 23:20
  • What you are describing seems to be massive pain in the ass. I can't see it being economic to hack the EF and .NET even if it was possible.
    – Euphoric
    Commented Jan 28, 2020 at 8:27
  • I agree. It would be much better to have designed the library with this in mind. The idea of two instances of an entire assembly just had never occurred to me so trying to learn from this. It seems like I just need two AppDomains; one for each instance of my BLL/DAL pair. I think you could do that at runtime, but then every use of those libraries would be via reflection, and that would be ugly and without compile-time type checking, etc. At least without a wrapper or a common Interface
    – xr280xr
    Commented Jan 28, 2020 at 21:54

1 Answer 1

Reset to default
0

Yes, this is a version of command query separation where your DAL implements the separation of the commands and queries.

Refactor your DAL to take two connection strings and run the commands against the updatable DB and the Queries against the read only db.

In practice I'm not sure how much of an improvement you will see. If you are only doing a few updates then the load from them is low in any case. If you are doing many updates then you have the cost of syncing the DBs and the risk of out of date data.

You can get better performance gains from caching or data-warehouses

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.