0

I need to build a website and an application that communicate together, in both directions. I will be building the website with ASP.NET, and the application in C#.

I will be hosting the website myself, and it will be running on the same machine as the application.

I don't know what's the best technique to use to send data between the two. The C# app will need to be running all the time. Should I build a C# Console App, and then hide the console window? Or would some other kind of app be more appropriate?

I've been looking round the Web and found several different suggestions, including Sockets, Message Queues, Remoting and WCF. A few pointers would be much appreciated - I'm new to all of this.

Thank you.

EDIT The request-response pattern will be used, with the Web App always being the one instantiating the requests. This is what I meant by two-way communication.

The web app will send a request to the back-end app, the back-end app will perform some processing, and then send a response back to the web app. JSON will be used to send data to and fro.

I will be using SQL Server Express 2008 R2, and the back-end app will be the only one communicating with the database. The web app will mostly be concerned with the Presentation Layer.

The back-end app will have in-memory objects that are instantiated when the app is started (with data loaded from the DB), and then persisted to the DB (during execution and before closing). Will a C# Console App be ideal for this kind of thing?

Rachel
  • 1,722
  • 8
  • 29
  • 34
  • What kind of datasource will you use? in example MSSQL? – Eric Herlitz Dec 26 '11 at 12:41
  • @Rachel - what kind of communication will they have ? If it is simple data communication then your windows application can place it in the DB and the web application call pull it from the DB, otherwise go for WCF. – Bibhu Dec 26 '11 at 12:45
  • @Trikks Yes, I will be using SQL Server 2008 R2. My idea is to have only the C# application communicating with the DB, so that the Web App will be mostly concerned with the Presentation Layer. I will probably be using JSON to send data to/fro the two apps. – Rachel Dec 26 '11 at 12:47
  • @Bibhu The web app will be sending requests to the application. The application will perform some processing, and then send a response back to the web app. – Rachel Dec 26 '11 at 12:50
  • @Rachel do you want the connection to be persistent? OR will there be a trigger in order to kick off the connection? – tugberk Dec 26 '11 at 12:51
  • @tugberk The connection can be persistent. I still don't know what I should really use for the back-end app, and how to communicate between the two. Still really new to all this. – Rachel Dec 26 '11 at 13:47
  • @Rachel SignalR to rescue. You should really look at that project. It is ruthlessly awesome! – tugberk Dec 26 '11 at 14:27

3 Answers3

5

What you describe in your comment is typical three-tier application.

  • Front-end: ASP.NET application hosted in IIS
  • Back-end: .NET application running as Windows service (or WCF application hosted in IIS/WAS) with exposed web services. Front-end application communicates with this application using web services (or remoting).
  • Database: Accessed only by Back-end application.

Just to make it clear. Two-way has many meanings but common in this scenarios is that front-end makes call to back-end and back-end respond (request-response pattern). Back-end never calls front-end - such communication is very hardly achievable with ASP.NET application.

ASP.NET works on per request basis. Client calls your ASP.NET application and there is processing of the client request = that's where all logic runs. When the request is processed, the processing ends. So calling your ASP.NET application from back-end doesn't fit this unless you expose some special web service for back-end processing but even after that it will not correlate with your clients request processing without some internal state hold in ASP.NET application.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Yes, you understood my situation correctly. I will be using a request-response pattern, with the front-end always instantiating the requests, and the back-end being the only one accessing the DB. The back-end app should have in-memory objects that are loaded from the DB upon start of execution, and persisted before being stopped. So would a C# Console App be more suitable? – Rachel Dec 26 '11 at 13:43
  • Console app is never more suitable when front-end is ASP.NET. – Ladislav Mrnka Dec 26 '11 at 15:14
0

WCF might be a choice. You can build what kind of connection you need with WCF.

Also, I reccomend you to take a look at SignalR. It is a project which enables you to build a persistent connection between your web app and client app. (your C# app in this case.). In official words, SignalR is an async signaling library for ASP.NET to help build real-time, multi-user interactive web applications.

tugberk
  • 57,477
  • 67
  • 243
  • 335
  • I would rather not use third-party libraries for this project, but thank you for suggesting it. I have never used WCF before. If I build a WCF application, can I keep in-memory objects as explained in my question (updated)? – Rachel Dec 26 '11 at 14:04
  • @Rachel SignalR may look like a third party library but it is not. The main developers behind that project is the core members of ASP.NET team: Damian Edwards and David Fowler. and I bet that this project will be built into core ASP.NET in future releases. – tugberk Dec 26 '11 at 14:29
0

WCF would work and you may also want to look at consuming / writing a web Service but depending on if you want Sync or Async seem more like the question ..

MethodMan
  • 18,625
  • 6
  • 34
  • 52