WCF API – Using for Database Access by GUI

Architecturecdatabaseguiwcf

Originally I asked this question on Stackoverflow but I was suggested to move the question here.

I've asked this question a while ago in MSDN forums but I'd like a second opinion from StackOverflow since I tried this route and found some CONS, but I'd like to hear more opinions as well.

Scenario:

I have a windows service program, extracting data from files and inserting the extracted data into a MS SQL database. There is a GUI program which does some filtering and calculations and displays the SQL data in realtime. So the GUI basically displays selective records from the database at any moment. It should be also possible for the GUI to insert and update records based on rules. Also The data fetched from the Database can be huge and it would be also nice to allow remote access to the data by the GUI (not critical)

So my question in more details:

1 – should I create a WCF service in my Service program which provides some API to the GUI to access and update records?

PROS:

  • I can change the backend database and wouldn't need to update the GUI
    app.
  • The GUI would be sql free.
  • allow the GUI to directly access the Database and fetch and update
    itself.

2 – allow the GUI to directly access the Database and fetch and update itself.
PROS:

  • security already in place faster than option 1 easier to implement

  • changed in records can trigger data change rather than polling for
    new data for real time display.

  • The GUI can access data remotly if SQL database access is setup to be accessable
    remotely (a possible security risk?)

here is the original question: http://social.msdn.microsoft.com/Forums/pl-PL/architecturegeneral/thread/8ef537c5-9a79-42b5-a6a0-f7278d3f506e

Best Answer

I generally go for the option of having a good service layer between any two dependencies unless it is not possible. I am a big believer in TDD, and it is a lot easier to test anything you can mock or fake out to better control the behavior for which you want to test. Trying to mock up SQL Server isn't as easy as mocking a service. Additionally, GUIs are notoriously hard to test with any kind of consistency as they are usually changing and are sometimes very non-deterministic (multiple events causing multiple outcomes, etc.). With a service, you have the ability to set up a mocked service that implements the interface/contract. If done right, you can then take your time developing the GUI and writing tests for it prior to having to work out the database schema and windows service. I would also look at maybe having the windows service update the database through a service layer of some sort as well. It doesn't have to be a "web" service per se. In some ways, I've had luck with these kinds of things being done through a message bus. We used TIBCO's EMS, but you could easily use any JMS implementation and a .NET connector. The advantage of this kind of setup is that you could write your file data to a queue, have a service that takes the data from the queue and updates the database AND notifies your client(s) GUI to refresh their data. A variant of this setup could be that the service actually sends the data to the clients via this topic saving you the added bandwidth of having multiple clients (if you have them) from having to hit the database with a query on every update.

Related Topic