Looking for Data Access Layer protection advice

I'm currently involved in a very large supply chain management software system internal to where I'm employed. The system's UI is currently only implemented through ASP.NET, but we're in development of W开发者_如何学Cindows Forms and Windows Mobile Compact interfaces as well. We have a pretty good setup in terms of separating the interface, business, and data access layers, so we have successfully shared across multiple platforms. However, we have some security concerns for when we distribute our client-based interfaces to the customer.

Several of our data access libraries are distributed with the executable. Simply opening the compiled assembly in Notepad gives full view to any queries within.

For example, let's say we have a class called "User" who implements the method "GetName" as:

select name from user where id = @id

The problem is that anyone keen enough to open the compiled assembly in Notepad can now see column and table names. Sure, they may not have access to these, but I'd still rather not expose the schema if I don't have to.

The above is just a simple example. Am I going about the thought process incorrectly, or is there a way to protect our queries? (I'd rather not resort to using stored procedures for everything.)

I've thought of forcing out data access layer to be remote and communicating from the business layer via web services so that all database related information is on our internal server that we can protect easier.

If you want to remove the sql from the src, then you are looking at another layer like web services. While that hides your sql, the services themselves must now be public. So while those who peek cannot see the db schema, they can still see the data layout.

What the web services allow for is an easier way to make schema changes since now you just have to make sure the data output is always the same. It also allows for you to move, rename, and/or perform other maintanence with the schema's dbs. Finally, it would better allow you to pool db connections local instead of over a network and have more processing run at the server.