I'm implementing the onion architecture with webapi, service layer, repository, unit of work and the domain classes. I use also DI, using simple injector.

But my issue, is how can I implement a specific use case.

  • The webapi should have the ability to receive a batch of files from the ui. After they are received they should be parsed and the database should be updated with the parsed data.
  • The UI shouldn't be waiting for the request, so the user can go on doing his thing.

So, since i'm using entity framework context to access database and setting it's lifetime dependent on the http request on the DI container, how can i be able to process the files and storing them if my request it's already dead?

I'm looking for a elegant solution, but for now i didn't came up with none, so any help would be appreciated here.

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Commented Oct 31, 2018 at 8:46
  • already did, hope that's more readable now. Commented Oct 31, 2018 at 8:55
  • 2
    Background processing is usually done outside the standard http request. The files should be put in a queue of some sort and processed with worker running separately from the web server. This worker can have completely different setup and use EF outside the request.
    – Euphoric
    Commented Oct 31, 2018 at 9:44
  • For instance, the usage of a library like hangfire or quartz.net would be helpful here? Commented Oct 31, 2018 at 10:01

2 Answers 2


Usually the way this works from the API code would be something like this:

  • Receive request with batch of files
    • Add files to processing queue
    • Respond with 202 Accepted response

Your core code in the Onion architecture would know what kind of processing needs to be done and how to do it. When the code that monitors the processing queue pops the files off, it hands that to your processing logic.

NOTE: I'm not prescribing multiple applications or message queue servers, although they help with high volume scenarios. I'm merely describing at a high level of how to use your onion architecture with the logical pieces. The API layer pops things on to the queue, the processing layer pops things off the queue. When work is popped off, it is provided to your core application.

If you have a need to track the progress of your submission, then you also need to return a tracking token. The UI would pass that tracking token to an API endpoint to get status. That call would be synchronous since it should be a quick check. You'd be in charge of the format of that response.


You need a third program

  1. The UI (webpage?)
  2. The web api (.net webapi hosted in iis?)
  3. The worker (.net windows service?)

The UI sends the files to the web api

The web api saves the files (without parsing them) to a database, queue or whereever and returns "queued" to the UI

The worker reads files, parses them and updates the database at its own pace.

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.