I am currently developing a WPF client application which uses Linq-to-SQL for the typed table objects and to wrap around an abundance of CRUD stored procedures in a MS SQL database on an external server. I do not foresee manipulating data directly via the context, only the stored procedures.
My two biggest concerns are: 1) Database security 2) Flexible architecture
As far as I can tell, since the application will be readily available for download via the internet, storing database connection information in the application itself is not an option (for security reasons). I feel my only option is putting my DAL in a web service.
User credentials can be passed along on a per-operation basis and database connection information will be stored safely on a secure web server.
I am curious as to whether this is method is valid, and if so is it optimal? Can I easily serialize Linq-to-SQL objects (table and stored procedure results) to send back and forth between the client and the web service?
Thank you in advance.
You are right, if your application is used over the internet, you pretty much have to put a middle tiers in there.
If what you are doing is primarily CRUD, I think a good idea would be to take a look at ADO .Net Data Services. It’s an efficient way to expose data through a REST interface, and you get a client library to access your data in a typed manner on the client side.
It supports the usual ASP.Net security mechanisms (such as Forms authentication, membership provider and so on) so that you can secure your access points based on the user’s credentials (and for that you can use the Client Services that can take care of authenticating between your app and your server).
Hope those pointers help.