Software architecture dilemma

[armen_shlang]

Hello,
I have a software and I cannot decide which approach would be the proper method. I blame on lack of experience!

So I have a Windows Service running in the background, and it's populating a database every 1/2 a minute. The Db is a flat file DB (Sql CE), which might/might not be replaced with a server DB.

Then there is GUI that needs to query the DB, and display the result in human readable form. Preety standard right..!

So here is my dilemma, would it be better for the GUI to access to DB directly to get/insert data, or connect to the Windows Service using WCF and make requests that way?
I should mention, the Windows Service would already have a WCF service running, to service a silverlight version of the GUI.
Thanks in Advance...

[Arjay]

I'd opt for Option 2.

Keep in mind that the Windows service will need to host a 2nd WCF service (along with the wcf service that is used by the silverlight app).

The Client Windows app would talk to the 2nd wcf service (which would talk to the db).

[armen_shlang]

Thanks for the reply,
What's the benefit of choosing opt 2? It would slow down transactions, and introduce complexity (if all ports are closed on the client machine WCF wouldn't work).

[Arjay]

Option 2 allows for scalability and a layer of abstraction.

Currently, the WCF service and database are hosted on the same machine.

You mentioned that you might want to host the db on a server in the future. When you move to that, you might have security concerns (use integrated security? Sql un/pw?). If the database changes, do you want to have to change all the clients?

With a WCF service between the client and the db, you have much more flexibility in terms of transfer protocol, security and abstraction. You might choose to change the database underneath the service. This could be transparent to the user.

With a WCF service, you also have clustering options and can easily cluster the WCF service across nodes (and also cluster the database).

Finally, you mention that the app only updates the database every 1/2 minute. This is practically no load, and adding WCF layer isn't going to impact performance, so why not build the system with the scalability and flexibility that a WCF service will provide?

[armen_shlang]

Thx for the reply.
Good points. I'm not too familiar with security concepts, but I understand the abstraction idea.
The only reason why I'm hesitant to do so are two reason:
- introduction to complexity
- Windows App would be dependent on the server app

[Arjay]

There is a slight bit of added complexity, but WCF services are quite easy to maintain once you go through the initial learning curve. In this case, the WCF service is little more than a wrapper to the database (and the abstraction it provides is a good thing).

The client app is always going to be dependent on the layer it connects to. The question is do you want it to be dependent on something that may likely change (i.e database schema may change when new functionality is added or changed)?

The abstraction that the extra WCF service layer provides allows you to change the database schema without impacting the client. You could even change the complete data storage mechanism without the client knowing.

Btw, I tend to think in terms of enterprise systems when I code, so that means I use stored procedures to communicate with the database, rather than direct table or LINQ access. I also don't ever have clients communicate with a database directly, because this approach ties me to the database. If I changed the db schema and didn't use stored procedures, all my clients would have to be recompiled.

With a WCF service layer, often times you can make database changes without impacting the clients. When new functionality is added, the WCF contracts allow versioning so old clients can contact a newer WCF service without breaking and updated clients can get the newer functionality. This flexibility greatly helps during deployment and offers staged deployment scenarios.

A few years ago I did some custom work for a customer who owned a grocery store. He wanted some employee scheduling software that used a biometric hand scanner to log employees in/out.

Employee info/timeclock data was stored in a Sql db and there was a Windows service to retrieve the timeclock data from the hand scanner as well as a WPF app that allowed users to schedule employees, create shifts, etc.

The Windows service and WPF app talked to WCF service(s) rather than the db directly.

About a year after I wrote the system, he added a 2nd store. The 2nd store was on a different network domain than the 1st store. It was painless to setup the scanner windows service and WPF app in the 2nd store. Had I chose to not use the WCF service layer, it wouldn't have been so painless to bring the 2nd store online.