4

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

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
1
  • you are definitely right about the mocked service. I didn't think about it at first, thanks. That was a good answer.
    – ArmenB
    May 23, 2012 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.