We have a large n-tier VB.Net winforms application with a SQL back
end. Over the last few days we've been discussing the preferred
method of connectivity for remotely connected clients. We have had
inconsistent results with the client connecting over the internet
directly to the SQL server. We are about to test the application
using remoting instead. I was hoping I could get some professional
opinions from this NG about this topic. Specifically I am wondering
if the performance would be better/worse/same, and aside from that,
would using remoting (http) allow the app to better deal with a
potentially volatile internet connection? The architecture we are
using is outlined in Rockford Lhotka's book "Expert vb.Net Business
Objects"

http://www.apress.com/book/bookDisplay.html?bID=198

First, I'd say that you should never expose your SQL Server directly to the
Internet -- the security risks are simply far too great. Given that, you may
want to choose between web services and remoting depending on the needs of
your application. Here's an article that discusses your options and why you
might choose each:

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconchoosingcommunicationoptionsinnet.asp

Once you do this, the next step I'd recommend is that you never allow
clients to directly pass SQL statements to your service -- a malicious
client could potentially cause great damage. Instead, your interface should
expose methods for perfoming the specific tasks that need to be performed,
e.g. GetCustomer(), PlaceOrder(), etc.

Using either a web service or remoting will also somewhat help in relieving
your network reliability issues. Remoting logically uses a connection per
call (although behind the scenes .NET may reuse a conenction if its still up
and running) so momentary network lapses often don't cause problems (no
guarantees though). If you want to go with a remoting framework that
provides greater reliability, I'd recommend the GenuineChannels product
(www.genuinechannels.com). This product replaces the built-in TcpChannel and
HttpChannel with ones that include the ability to catch and handle
short-lived network errors.

As for performance, of course you will take a slight hit for ever layer you
add in between your client and the data. But compared to the inherent
latency of the Internet and all the other factors that wight in, I don't
think this should be a real consideration. The benefits of such an
architecture will far outweight any (very) slight performance degradation
you may experience.

Ken


[quoted text, click to view]