Your suggestions basically look reasonable.
The question also contains one of the most reasonable suggestions for communications between UI and device layer: that could be WCF. In this case, the most adequate WCF hosting would be self-hosting in the device-layer application, which could be Windows Service, which is well suitable for WCF hosting. Alternatively, you could use "classical" remoting, or lower level, such as TCP sockets (
TcpListener on service side,
TcpClient on client part) or named pipes. Note that such kinds of transport can become WCF
channels, which can be replaceable/configurable, for better flexibility. This choice would be the in some more detailed level of your architecture. The most important point here is: devices should be services, not clients. You can hide device implementation detail behind the common interface. By the way, if you have different types of devices and need several different interface, each such device of group of similar or related devices could be implemented as a separate service.
For threading issues of the services, see also my past answers:
an amateur question in socket programming[
^],
Multple clients from same port Number[
^],
How Do I Get To Know If A A Tcp Connection Is Over[
^].
Such approach to devices creates other benefits. Not only you isolate them from UI, data layer and other aspects, you can put them in a different
tier (not to be mixed up with layers!) You can debug the device services using one client application, but your product client applications could be different. You can place your device layer on different platforms. In case of WCF, you may think that it could defeat the benefit of the
service contract, which are very convenient but are specific to .NET, but then you should remember that CLI and WCF are also available on non-Microsoft platform, for example, via Mono and/or other 3rd-party platforms (say, CosmOS). Even if you think that you don't need other platforms now, the extra flexibility you put in the architecture will open the multiplatform opportunities to the future versions of your product.
The second question, "where to instantiate DB interface" is not clear. I cannot understand what do you mean. You already suggested a separate data layer, which is very reasonable. You can find a lot of reading on the architecture of data layers and their place in the application architecture.
The most important part to abstract out from other aspects is UI. This is in part due to some historical/cultural reasons. The UI computing is the least stabilized part, the UI designs use different frameworks and are the most "fragile". I suggest you learn and analyze applicability of the following
architectural patterns (
http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)[
^]):
MVVM — Model View View Model,
http://en.wikipedia.org/wiki/Model_View_ViewModel[^],
MVC — Model-View-Controller,
http://en.wikipedia.org/wiki/Model-view-controller[^]),
MVA — Model-View-Adapter,
http://en.wikipedia.org/wiki/Model–view–adapter[^],
MVP — Model-View-Presenter,
http://en.wikipedia.org/wiki/Model-view-presenter[^].
—SA
Submit an article or tip