为了保护将要由多个客户端访问的数据库，将Web服务用作代理是否过大？

Question

we're going to have a database, and a client application that is going to be installed on several machines in a local network, and they must be able to access the DB.

Some of them must be able to edit and modify the DB, and some of them are going to just read them. each of these two groups are separated to several groups too, based on who must be able to access to which table/field.

To create this application, we were gave an advice to deploy a web service to role as a proxy between clients and the DB, in order to secure the DB.

But we're not transferring any sensitive data (such as credit card numbers or...) and we're only afraid of not an unauthorized person be able to modify the DB.

Isn't just using the integrated security option in the app.config sufficient?
Do we really need to hide and secure the connection string?

Answer 1

Sounds way overboard to me. If the application is only going to be used internally, and Windows authentication is an option, certainly use it. Building a web service is only going to slow down development and add an unnecessary layer of complexity. The read/write users could be members of a Windows group that has read/write access to the database, and the read-only users could be members of a Windows group that only has read access to the database. Then, if the user is able to gain direct access to the database (without using your front-end) they would only be able to either read or read/write based on their Windows rights.

Answer 2

It could be overkill, but it might not be. Deciding to go to a Service-Oriented Architecture could be based on several factors, among which:

• How long are you expecting to maintain this application?
• How many client deployments are you expecting?
• Do you expect your database to change often?
• What are your SLA requirements?
• Do you expect the database to eventually be used for other applications?
• etc...

The long and short of it is, if you want to be able to change things in the middle tier or database, and you don't want to have to upgrade every client when you do so, adding a Service layer might be the way to go. You also have the advantage of providing a rich API for other client developers (internal or external) while controlling business rules and security in one, centralized location.

SOA definitely adds to the complexity of the project, but in many cases, it can save you a lot of headaches in the future.

For further reading, look at http://en.wikipedia.org/wiki/Service-oriented_architecture , http://www.soapatterns.org/ , or Google.