My WinFroms application uses tableadapters & datareaders to fetch data from an SQL server.
I am thinking of replacing the datareaders stuff with web services for security reasons. I guess one of the cons will be the execution speed.
Is it true? Or...
Web services definitely have a higher overhead in terms of execution speed - purely because in a typical SOAP implementation, the data you are bringing back will be wrapped in XML. So you'll be pulling more raw info down and then asking your app to parse it into the correct types.
I'm not sure how you plan to use web services to benefit your security situation. Bear in mind that you'll need somewhere for these services to live, and that your client application will need to be able to hit that location.
Using netTcpBinding or netNamedPipesBinding, the performance won't differ that much. These bindings use a binary encoding over TCP/IP or Named Pipes, respectively.
Yes, you will get better security, since you won't be connecting to SQL Server directly from each client.
You may even have some opportunities to improve performance. If you happen to be making a number of small calls to the database, then consolidating them in a larger WCF call can actually improve performance.
Surely the security of your application as it is now depends on how you connect to the MS SQL DB. Do you authenticate your clients when they use the application at all? I have seen plenty of instances where the user logins are actually SQL logins and this is what provides the security and can allow data segmentation in the DB based on those logins quite natuarally.
If you only have one login, which I hope is not SA, connecting for all the users of your application then having a seperate Data Access Layer sounds a sensible design choice. You are obviously thinking of web services for this layer but you could also consider other options. Maybe these SO questions might help;
Yes, you'll get better security - adding layers always helps, especially if you then take steps to protect each one. For example, if you only allow access to the web service and allow access to the sql server from your web server only, then you've reduced the target area hackers could use to get at your sql server.
Of course, now you're in the position where they need to hack your web server to be able to get at the sql server. If you further reduce the area by putting the web service code into a service and only allowing that to access your sql server then you're doing a lot better - the web service code acts solely as a wrapper to the middle-tier service; now they need to hack the web server which will only let them get access to the service, and that will contain your proprietary interfaces that should be more difficult to hack (assuming the hackers are attacking your web and sql servers using known security flaws, eg 0 day attacks).
I know several places that are paranoid on security (financials mainly) here the web server is considered a security risk, so very little is run in there - it acts as part of the presentation tier solely to pass data through to a secured service, that in turn manages a secure connection to the data tier.
See Roger Session's article on Software Fortresses for an introduction.
As for speed.. well, nowadays servers are so fast you can take an object, convert it to SOAP, post it over HTTP, parse it, unpack it back to an object and call the method you wanted all along without too much noticeable delay. Of course it's slower, but if you can scale it so it is fast enough, then who cares nowadays?