Remote database access layer

[Guest]

Dear Groups,

I am trying to develop a simple client <-> server application where (for
database security reasons) the server only has access to the centralised
database (and a file repository), and not the client.

I think the best way to do this is to expose data layer objects using
Remoting to the client.

This sounds almost like a design pattern to me, but I can't seem to find
anything on MSDN that will get me started with a client and server remoting
application which will allow me to execute SQL and return datasets and make
requests for other binary data (say, to return a file on the filesystem).

Does anyone know of a good place to start looking for some shell code which
I can examine to learn from?

All I would like to see at this stage, is a client application creating and
returning remote datasets and executing remote sql statements. This would be
wonderful!

Thanks!


--

Liddle Feesh
*fap fap fap fap*
<>< <>< <>< <>< ><>
<>< <>< <>< <>< <>< <><

 

[Rafal Gwizdala]

Dear Groups,

I am trying to develop a simple client <-> server application where (for
database security reasons) the server only has access to the centralised
database (and a file repository), and not the client.

I think the best way to do this is to expose data layer objects using
Remoting to the client.

This sounds almost like a design pattern to me, but I can't seem to find
anything on MSDN that will get me started with a client and server
remoting application which will allow me to execute SQL and return
datasets and make requests for other binary data (say, to return a file on
the filesystem).

Does anyone know of a good place to start looking for some shell code
which I can examine to learn from?

All I would like to see at this stage, is a client application creating
and returning remote datasets and executing remote sql statements. This
would be wonderful!

Thanks!


--

Liddle Feesh
*fap fap fap fap*
<>< <>< <>< <>< ><>
<>< <>< <>< <>< <>< <><

Well, a much more common design pattern is to expose the exact application
server functionality to client, not a universal database or filesystem
access layer. Exposing full db / filesystem to clients isn't secure at all,
and this is the main reason why it didn't become a design pattern.
You should define the exact functions that clients will need from your
server (functions that perform ONLY the necessary tasks and cannot be
maliciously used to get unauthorized access to the server) and make them
accessible via Remoting or Web Services or whatever protocol you like.

Best regards,
Rafal Gwizdala

 

[Beth Massi [Architect MVP]]

Passing ADO.NET datasets back and forth from client to server is not an
uncommon thing to do since datasets are serializable and easy to work with
as long as all the clients and servers are written in .NET. In particular,
Windows Forms clients work very well with remote objects returning datasets.
However, if you want to use secure .NET remoting I would make sure to read
up on IIS hosting remote objects. This uses the HTTP channel, but you can
use the binary formatter so that can cut down on the size of the
transmission. However in .NET 1.1, datasets don't actually serialize as
binary so you have to use a surrogate class. .NET 2.0 fixes this issue but
for now you can use this code:
http://www.gotdotnet.com/Community/...mpleGuid=ce9bf223-9236-42e7-b918-2b80a4e30f49

Typically you would define a series of "Get" methods on your remote object
that would return datasets to the client. The remote object should inherit
from MarshalByRefObject and always return serializable classes/return
values. You can also achieve the best scalability by creating Single-call
server objects (they are also easy to web farm or turn into web services if
necessary). Here's a good article on different remoting options:
http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html

HTH,
-B