M
morleyc
Hi, until recently i was quite happy to add data sources from mssql
database in visual studio and drag the datasets directly onto the form
this creating a directly editable form which worked well.
However i have recently started a project which will require
synchronization to a remote database. Also the underlying database
provider may change at a later date. From what i have read it seems
that a layered approach is necessary, or at least recommended, where i
present an object to the form to be bound (i guess this is called the
business object in technical terms). The business object would then
communicate with a data layer which would then write to the database.
How easy is it to bind business object fields to the form? I don't
want to be hampered too much productivity wise messing with additional
coding. Will the business object controller have to return a list of
business objects? i.e. the function call in the controller layer
BusinessLayer.GetAllCustomerOrders(uint customerID), would return a
BindingList of type CustomerOrders?
Are there any standard interfaces the business object layer would use
to talk to the data layer?
Also, if i take a hit on portability to other platforms which is
unlikely at this stage, is it recommended for the business layer to
return DataSets directly? Although encapsulating a DataSet within the
business layer and presenting it as an object with fields is nice and
abstract, i can see a big time penalty. I would be prepared to return
DataSets if it would provide a happy compromise between segregation
and speed of development.
Finally, i need to synchronize the data in one database to another
database. Where would this synchronization take place? In the business
layer when a delete or addition is performed, i could (as i would be
in my Add or Delete function) perform two data access modification
calls, one to the local database and one to the remote database.
Another snag is that the databases cant be an exact synchronization as
the remote database would contain records for many users (many clients
will be adding to this hence the field IDs will not match between the
local and remote databases), would it be sensible to have a RemoteID
field in my local database row for each record? I'm thinking if that
field is empty the field hasn't been synchronized yet (the remote
database AddRecord function could return an ID which would then be
stored in the RemoteID field in the local database), when i delete a
record in the local database i will be able to delete the record in
the remote database by using the RemoteID field. Or would i base a
primary key for the table on the UserID and the local record ID? That
would indeed make a unique key but is it possible to define a primary
key with the composite of two fields? I hope that isn't too confusing
and illustrates my thoughts on howto solve this multiuser to singe
user database sync.
Thanks in advance,
Chris
database in visual studio and drag the datasets directly onto the form
this creating a directly editable form which worked well.
However i have recently started a project which will require
synchronization to a remote database. Also the underlying database
provider may change at a later date. From what i have read it seems
that a layered approach is necessary, or at least recommended, where i
present an object to the form to be bound (i guess this is called the
business object in technical terms). The business object would then
communicate with a data layer which would then write to the database.
How easy is it to bind business object fields to the form? I don't
want to be hampered too much productivity wise messing with additional
coding. Will the business object controller have to return a list of
business objects? i.e. the function call in the controller layer
BusinessLayer.GetAllCustomerOrders(uint customerID), would return a
BindingList of type CustomerOrders?
Are there any standard interfaces the business object layer would use
to talk to the data layer?
Also, if i take a hit on portability to other platforms which is
unlikely at this stage, is it recommended for the business layer to
return DataSets directly? Although encapsulating a DataSet within the
business layer and presenting it as an object with fields is nice and
abstract, i can see a big time penalty. I would be prepared to return
DataSets if it would provide a happy compromise between segregation
and speed of development.
Finally, i need to synchronize the data in one database to another
database. Where would this synchronization take place? In the business
layer when a delete or addition is performed, i could (as i would be
in my Add or Delete function) perform two data access modification
calls, one to the local database and one to the remote database.
Another snag is that the databases cant be an exact synchronization as
the remote database would contain records for many users (many clients
will be adding to this hence the field IDs will not match between the
local and remote databases), would it be sensible to have a RemoteID
field in my local database row for each record? I'm thinking if that
field is empty the field hasn't been synchronized yet (the remote
database AddRecord function could return an ID which would then be
stored in the RemoteID field in the local database), when i delete a
record in the local database i will be able to delete the record in
the remote database by using the RemoteID field. Or would i base a
primary key for the table on the UserID and the local record ID? That
would indeed make a unique key but is it possible to define a primary
key with the composite of two fields? I hope that isn't too confusing
and illustrates my thoughts on howto solve this multiuser to singe
user database sync.
Thanks in advance,
Chris