How should we approach layered-architectures that need large amounts of continuous communication?

by Nick Miller   Last Updated September 14, 2018 16:05 PM

Background

In much of the literature I've read online with respect to multi-layered architectures, many people describe how to create the simple application where:

  • UI presents static model objects to the screen.
  • Users can make one-off requests (e.g. send e-mail, commit payment).
  • A database transaction is typically made to return new information to show to the screen.

Often, the articles will describe these concepts while adhering to Eric Evan's Domain-Driven Design.

Problem

Despite the good resources online, there isn't much guidance for applications that need to be continuously communicating with external devices. Consider the following:

  • An e-mail client should continuously query a POP server to know when new e-mail has arrived.
  • A device monitor should continuously query the device's status variables to always display the live values (e.g an aircraft HMI might depend on the visibility of hundreds of variables at all times).

My understanding is that there are two viable solutions for this type of I/O in the multi-layered context.

  1. The UI layer can make use of background-threads (e.g. .NET's BackgroundWorker) to continuously make queries to application services which return ONLY the data required by the view in question.
  2. A background thread in an infrastructure service can continuously query ALL relevant information from an external device (perhaps by relying on some configuration) and send events/notifications to other layers so that the UI can react. While personally not a fan of it, an event aggregator can be helpful to this end.

I think that solution #1 is better aligned with the examples I've come across, but my concern is that this is NOT a scalable solution. As the amount of continuous I/O increases, spinning off many background threads (for each view) not only causes us to violate DRY, but it degrades performance because of many, small I/O requests instead of few, large I/O requests.

How should we approach multi-layered architectures that need large amounts of continuous communication?



Related Questions



Can I manage transactions in the UI

Updated May 07, 2016 08:02 AM


Cross Entity Action Implementation

Updated December 10, 2017 02:05 AM