I've put together a basic server and client in remoting. In order to
pass data around I presumed you'd use the detached objects like DataSet,
DataTable and DataRow so I figured I'd define a DataSet class in an
assembly that was shared by the client/server (along with the interfaces
for the server) and then add a couple of methods:
Fill(ref DataSet aDataSet, string aTableName);
UpdateData(DataSet aDataSet);

The idea being that these would be generic methods allowing the client
to pass a DataSet object to the server to have one of it's tables filled
or to send updates back to the server.

It seems like there's actually a fair amount of work involved in order
to write the generic UpdateData method though - I have to build up a
DataAdapter, set the TableMappings and the FieldMappings and finally
build the Update, Insert and Delete statements (all of which I was just
going to generate automatically - for example, to do an update I'd do
"Update [All fields except the PK] WHERE PK = [Original PK]" - in my
case if I want to do anything fancy then I'll typically do it in the
triggers for the table/view that I'm updating in the actual databases
themselves, so no need to do anything but plain jane default stuff in
the insert/update/delete statements in the .NET remoting server).

Then I got to thinking, this is ridiculous - surely someone has bumped
into this problem before me so I went scouring the internet for all and
any posts I could find relating to remoting and datasets. Remarkably I
came back with very little and certainly nothing that discussed sending
updates back to the server or handling these.

I did find the odd post from folks that suggested DataSets + Remoting
was a bad idea, with various others fervently replying that they agreed,
but they didn't go into any details as to why this might be the case.
Perhaps it was for performance reasons in which case maybe simply
serializing the datasets in binary format rather than XML would help or
using something like GenuineChannels might do the trick.

So, a couple of questions:

1. Is there anything I should know about why using DataSets + Remoting
might be a bad idea?

2. Presuming it's not such a bad idea as all that (it seems like the
docs for .NET encourage using these in remoting situations at least)
does anyone know of examples or tutorials or even just passing
conversations/blogs anywhere that discuss more specifically sending
DataSet updates back to a remoting server and handling these?

Any help appreciated.

Best Regards,

James Crosswell
Microforge.net LLC

James Crosswell <james@microforge.net> wrote in news:#Y7naj4VHHA.5068
@TK2MSFTNGP03.phx.gbl:

[quoted text, click to view]

Is there a reason you like to do this? ADO.NET can be used to update a
remote database.

[quoted text, click to view]

Absolutely, writing such a layer is not trival... You're better off
using an ORM mapper for this type of work - like LLBLGen Pro. LLBLGen
Pro has a dynamic SQL engine which you can leverage for this type of
stuff. Other popular ORM mappers include Codesmith and NHibernate.

You'll also have to build a robust security layer since you're exposing
the entire database.

[quoted text, click to view]

Datasets and remoting are not inherently bad - but they should be used
in moderation. Sending too much data across the wire (in your case
entire tables) could quickly swamp network resources.

Also, since datasets are disconnected, you'll have to reconcile changes
- so perhaps it's best sending as little data as possible to client.

If you want to send table dumps across the network, there are better
protocols out there. Perhaps dump the raw CSV, or the database's native
features like Bulk Updates, DTS or SQL Server Integration Server.

Also from a SOA/tier design perspective, clients who use your generic
database server will need to have intimate knowledge of the DB schema.
In that case, why not connect directly to the database with enterprise
manager or ADO.NET - you're sort of reinventing the wheel? Since you're
exposing database tables to end users (developers?) who may not know the
database well, you should expose specific function calls like in a web
service. For example: ListUser, AddUser, DeleteUser, SaveUser, etc. This
way the end user will know exactly what each function does and your
remoting server provides a clean abstraction from the database
implementation:

User --> Remoting Server --> Business Logic --> Data layer code -->
Database

[quoted text, click to view]

Sending datasets is nothing magical in remoting ... but I think where
you're having trouble is in your generic data layer? The problem you
seem to be having is how to build the generic connectors required to
access a table in a generic fashion? If that's the case - that is more
of which how to implement your data access layer than a remoting
problem?

Remoting datasets should serialize fine ... so you should be able to get
the dataset as an object on both sides of the connection.

Hi, James:

Let me give you inputs about my concerns. See my inline comments.

[quoted text, click to view]

Overall, I don't recommend you to remote dataset or datatable across
across machines. It is a wrong approach unless you are sure that your server
just supports a limited number of clients on LAN only.

[quoted text, click to view]

If I were you, I will use parameterized statements for insert, update and
delete. Suppose that you need to update a set of records, I will use
something following:

Update Table MyTableName Set AColum = ?, MySecondColumn = ? Where
SomeKeyColumn = ?.

Use this way is perferred for better generics and speed. Note that ADO.NET
doesn't have so good generic data accessing support as OLEDB. You may be
forced to use OLEDB .NET provider. You can also see our sample at
http://www.udaparts.com/document/articles/asyniis.htm. Inside the sample,
you will find a simple to show you how to use parameterized statements for
these purpose. That sample supports all of data sources (Access, MS SQL,
Oracle, DB2, mySQL, ......) through OLEDB technology.


[quoted text, click to view]

GenuineChannels solves a set of problems that MS .NET remoting should not
have. MS remoting implementation is really BAD from my view, although it has
a good archtecture. However, I do NOT think that GenuineChannels is able to
help your application performance at all.
[quoted text, click to view]

It depends on how many clients and network types. It may work very well with
a few clients + LAN networks.

[quoted text, click to view]

Actually, it is bad idea. You can't assume it is a good idea.

[quoted text, click to view]

[quoted text, click to view]

Like via a direct connection to the database you mean? If so then that
would be the reason I want to do it via a middle tier - there's no way
I'm opening a port on the internet to my DB Server and besides, running
queries directly against the database will quickly get inefficient in a
distributed application (sometimes all I need to pass to the middle tier
is a little packet of data which the server deals with by issuing 10-15
serparate queries... if I ran those directly against the SQL Server over
the WAN then the same operation would take about 20-30 times as long).

[quoted text, click to view]

Yeah I've been looking at one (which I already own by default, becuase
of a subscription I have) called XPO (Xpress Persistent Objects). So far
I haven't had much luck with it - in a local app the framework is great
but I can't seem to persuade any objects I derive from their base class
to serialize.


[quoted text, click to view]

Indeed - I had planned on the security layer anyway.

[quoted text, click to view]

I hadn't actually planned on sending entire tables - the DataSet in my
case will include DataTables but these DataTables won't include ALL of
the information in the underlying database table... in the GetDataSet
method for my remoting service I was going to pass in various
criteria/filters so that this would return only pages of data (ala
google search results).


[quoted text, click to view]

Agreed - I see the DataSet has a GetChanges method for this purpose
which I can use to send the Delta back to the server.

[quoted text, click to view]

As I say, I have no interest in sending a dump of an entire database
table - the DataSet just seemed an appropraite container for the limited
result sets that I wanted to pass back since it took care of stuff like
marking records as Inserted/Deleted/Updated, generating Deltas and just
generally being a data centric class that I could easily map all my DB
records to whilst maintaining compile time type checking.

[quoted text, click to view]

That's OK - I'm not building this app for other people to consume - only
inhouse clients. Remoting was simply going to be communication channel
between the various processes involved in the solution.

[quoted text, click to view]

Surely I don't have to describe the benefits of using a middle tier in
the remoting newsgroup? I'm familiar with distributed application
architectures and programming in general.

[quoted text, click to view]

That would be one approach but, as I say, this service isn't being built
to be consumed by the public at large and the building of specific
methods like that would just slow down development and testing.
Internally all those methods would use a generic/refactored internal
method anyway so why not just promote that generic method to the service
interface?

I have written distributed applications (in other frameworks) using both
of the approaches (one set of methods per object type and then just one
set of generic getdata/updatedata methods) and the later is by far
superior. Now I'm just trying to work out how this can be done in remoting.

[quoted text, click to view]

Exactly - I can send back a particular datatable and update this using a
method that makes use of a proprietary DataAdapter (code generated by
the DataSet wizard) for this particular table but that's not what I
want. I want a generic DataAdapter that will allow me to update any of
the tables that is defined in the dataset.

I can do this very easily using the remoting framework that I have been
using to date (RemObjects and DataAbstract) so I was kind of surprised
that something which people have to do so commonly in distributed
applications (retrieve and update data) seems to be so inordinately
difficult using Microsoft's remoting framework.

Best Regards,

James Crosswell
Microforge.net LLC

[quoted text, click to view]

pff. I've been building distributed applications that work and perform
extremely well over 56k dial up connections with tens of thousands of
records in the underlying databases using Delphi for years...

Now when I move to .NET it seems this is still an extremely difficult
task in .NET? Surely I'm dreaming - there must be a way to do this...

The sample method declaration that I gave above for GetData was a
little misleading and oversimplified - I'd obviously pass in some
information that could be used to filter the specific rows from the
underlying table that were returned (so I'm not planning on returning
all the rows in the table). My main problem here is building a generic
"Update" method that could be used to update all and every table in the
DataSet that the service works on.

Best Regards,

James Crosswell
Microforge.net LLC

[quoted text, click to view]

btw: sorry if the pff seemed like it was directed at you - it was more a
pff of frustration. I appreciate your having taken the time to respond
and your comments I'm just sure there must be a way to do this that
doesn't involve writing 100 different methods for my remoting service
which all look almost identical.

Best Regards,

James Crosswell
Microforge.net LLC

James Crosswell <james@microforge.net> wrote in news:O4PA$9zWHHA.488
@TK2MSFTNGP06.phx.gbl:

[quoted text, click to view]

Well it's Wednesday, we're 1/2 way towards the weekend :-)

I'm not sure if Datasets are the best method to do what you want to do...
how about creating a set of Data Transfer Objects which inherit from a base
class? Then in your method you would pass:

Public Function Update(ByVal DTO as BaseDTO) as Boolean

Your function can do some reflection to figure out what type of object it
is and proceed to update the appropriate tables? I've done something

[quoted text, click to view]

That seems to be the route I'm headed down yes... in fact I kind of
switched over to WCF instead of remoting (since this seems to supply
quite a bit of extra functionality) and I'm just in the process of
resolving some problems serializing a class from the OPF (Object
Persistence Framework) that I'm using which are in a third party library
and aren't serializable out of the box.

WCF supplies something called an IDataContractSurrogate that it seems I
can use to pretend that these objects are actually serializable and if
it all works then I think I should be all good :-)

I'll see how it goes, there seem to be quite a few things WCF doesn't do
out of the box but it can be customized to do almost anything
(serializing circular object graphs etc) which is reassuring!

Thanks again for your input.

Best Regards,

James Crosswell
Microforge.net LLC