> Isolating the database to libraries is usually the best
> approach. Database independence is being able to move to
> different DB's without code change outside the database.
> This is often a pipedream IMHO.
<beating mode="deadhorse">
only if you use stored procedures or hand-written SQL ;)
</beating>
I mean:
CustomerEntity c = new CustomerEntity();
c.Companyname = "MyCorp Inc.";
//...
IDataAccessAdapter adapter =
DataAccessAdapterFactory.GetAdapter(SupportedDbs.Oracle);
adapter.SaveEntity(c);
or I could have done:
IDataAccessAdapter adapter =
DataAccessAdapterFactory.GetAdapter(SupportedDbs.SqlServer);
adapter.SaveEntity(c);
where that factory is a simple factory which creates the proper
DataAccessAdapter instance for the db to use.
And with this, all data-access is done, without any db specific stuff. This
means that you can have a single set of domain objects,
bl tier and gui and just a bunch of db specific generated projects (or mapping
files if you use an o/r mapper which uses mapping
files, not attributes!) which take care of the db specific issues, like type
conversion, table/view mappings etc.
data-munging procs are great for the purpose of data-munching, but also
make your app db specific. Often an app doesn't need
these.
Also, please take into account that any db vendor really likes you to
write procs, as these aren't portable, so the more
procs an app has, the more certain the db vendor is that the application
developer stays with the database vendor.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
