So normally a midtier will generate a webpage for the viewer/browser
I'd disagree slightly with this. I'd say the midtier would generate the data that can then be consumed by the view. The view could be an ASP.NET WebForm, an ASP.NET MVC razor view or it could be a WinForm in a C# desktop application.
If you want true separation of data and view then you should probably consider making the backend of your system a web service that can be consumed by either a website/web application or a desktop client/binary e.g.
SQL DB + File System -> Business Logic/Mid-tier -> View (Web/Desktop/Mobile)
Your first view implementation would be the Desktop C# binary view.
And more importantly, how do i push updates/notifactions from the DB to the midtier and then to the c# app ???
Based on this I'm assuming that you want the C# application to instantly receive the updates and that although your app isn't a web app (HTML/JS etc.) it is in fact a web client.
Notifications like this tend to be achieved in a few ways.
- HTTP Polling
- HTTP Long-Polling
- HTTP Streaming
- WebSockets
The latter is now the standard for real-time bi-directional full duplex communication between a client and a server. However, if the frequency of updates is very low then you could simply implement a web service which your C# client could poll at long intervals to check for updates.
If the update frequency is reasonable, and your requirement for Push notifications suggests it is, then I'd suggest a realtime push system and therefore I'd suggest using a WebSocket server and client. There are a number of WebSocket server and client examples available such as:
If you'd rather remove the need to implement and host your own realtime messaging infrastructure then you could consider a hosted realtime service.