Generic Data Access design problems

  • Thread starter Thread starter Radostin Gerchev
  • Start date Start date
R

Radostin Gerchev

Hi,

Every data adapter implementation (those in the framework and several other)
that i know has RowUpdating and RowUpdated events.Why aren't they in a base
class or interface, e.g. IDbDataAdapter or DbDataAdapter? Right now it's
pita to register a listener for them in a generic database layer - one have
to cast to a specific adapter.

I don't understand also the need for both common interface and base class
(IDbDataAdapter and DbDataAdapter). The other data-related classes just
implement an interface - IDbCommand, IDataReader, IDbConnection ..., why ?

I have similar design issues with all the CommandBuilders around - a bunch
of classes with identical signature derived from .... Component and not
implementing a common interface, why? The good news here is that
CommandBuilder is useless anyway except in the most trivial cases so not a
big problem.
 
Radostin Gerchev said:
Hi,

Every data adapter implementation (those in the framework and several other)
that i know has RowUpdating and RowUpdated events.Why aren't they in a base
class or interface, e.g. IDbDataAdapter or DbDataAdapter? Right now it's
pita to register a listener for them in a generic database layer - one have
to cast to a specific adapter.
Agreed.


I don't understand also the need for both common interface and base class
(IDbDataAdapter and DbDataAdapter). The other data-related classes just
implement an interface - IDbCommand, IDataReader, IDbConnection ..., why ?
Click to expand...

This is simply because the different DataAdapters share a ton of
implementation details. One basic job of the a DataAdapter is to take an
IDataReader and shove it into a DataSet. The IDataReader implementations
handles most of the provider-specific stuff, and so you only have to write
this code once if you put it into the DbDataAdapter base class.
I have similar design issues with all the CommandBuilders around - a bunch
of classes with identical signature derived from .... Component and not
implementing a common interface, why? The good news here is that
CommandBuilder is useless anyway except in the most trivial cases so not a
big problem.
Click to expand...

Agreed.

David
 
Thank you for the link. Good read but it's all about a wrapper around MS SQL
Server routines _ONLY_ and is exactly what i'm trying to avoid. Also they're
not using adapter interfaces/classes at all.
 
This is simply because the different DataAdapters share a ton of
implementation details. One basic job of the a DataAdapter is to take an
IDataReader and shove it into a DataSet. The IDataReader implementations
handles most of the provider-specific stuff, and so you only have to write
this code once if you put it into the DbDataAdapter base class.
Click to expand...

I agree with you, should've formulated my rant more precisely. Ok, let us
have a helper DbDataAdapter class but why not include some common properties
in the interface? Now I have to cast between IDbDataAdapter and
DbDataAdapter to get access to AcceptChangesDuringFill for example.

Best Regards
Radi
 
Can u send me your code. I have developed a Generic Data Access Layer. It could perhaps solve the problem. It is different than the other Generic Access solutions. It does not use switch construct to cast, etc. insteads uses an Xml configuration file and can be extended to MySql, Sybase, etc

You can check it out here www.maxvirtual.com/opensrc.aspx

It is currently quite popular since it is listed at : http://www.gotdotnet.com/community/resources/home.asp

It is still work in progress - but I think I can include your scenario.
 
Hi

Take a look at our Mimer Provider Manager (Mpm) at
http://developer.mimer.com/mpm or
http://www.sourceforge.net/projects/mimerpm. It's a framework for
abstract what database you use. Simply code against the Mpm-namespace
(MpmConnection, MpmDataAdapter and so on) and the system handles the
delagation to the correct Data Provider. It also handles things like
different usage of parameter markers. There is a Mpm Administrator that
you can use to define data sources outside your application and you only
reference these in the connection string. This makes it possible to
change your database without changing a single line of code. Mpm is
integrated in Visual Studio with wizards for creation of Data Adapters,
DataSets and with support for dynamic help, just as if you were working
with for example SqlClient.

You can read more at
http://www.codeproject.com/cs/database/MpmCodeproject.asp

Regards,
Fredrik
 
Back
Top