It is certainly possible to write code that can interact with any type of
database, and any schema. How this is done depends quite a bit on the type
of database you're interacting with, and it is even possible to
programmaticall y determine that, if necessary. However, it seems to me that
you're overlooking something. Business objects are designed to work with
data, and to manipulate it.
For example, a "Person" class might have a "FirstName" property that is
linked via a database table to a column named "FirstName. " Now, let's say
you added a column named "Foo" to the "Person" table in the database. Your
business class could certainly query the database to find the column, and
could even find out everything about that column in the database, what type
it is, how large it is, how it is indexed, etc. So, your business class
becomes aware that the column "Foo" now exists in the "Person" table in the
database. What does it do with it? It is, after all, a business class. It's
job is not simply to fetch data, but to work with it, manipulate it, use it
for something. So, what to do with "Foo?"
The database and the data layer know nothing about what "Foo" is. The data
layer is business-agnostic. It simply fetches and receives data, and hands
it off to be processed by somebody else. The database knows all about the
column, but nothing about what it represents. And of course, your interface
layer may be presented with this column. Of course, it may not. "Foo" may be
intended for use by the business layer only. But even if it is for the
presentation layer (which of course the business layer has no way of
knowing), and even gets handed off to it, what is the presentation layer
supposed to do with it? How should it be displayed? If it is in a form
(simplest possibility - it could be part of a graphic, after all), how
should the data be validated? Is it a string? If so, is it a phone number?
How should it be formatted? Is it a number? If so, how large or small should
it be?
An application is all about the data. The purpose of almost any application
is to enable a user to manage and/or use data in some form or fashion. Now,
if you're writing a database interface, like SQL Enterprise manager, which
is simply for the purpose of working directly with data AS data, and for no
other purpose, this sort of thing is useful. But data almost always
represents something. What it represents is anybody's guess. And how it is
handled depends upon what it represents, or what it is used for. And that is
what developers are for: To determine the requirements of the app, and how
the data used by the app should be handled.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"natzol" <na****@discuss ions.microsoft. com> wrote in message
news:80******** *************** ***********@mic rosoft.com...
Just a question to verify - I am a beginner in .Net
Our business needs require that we have to modify db tables on regular
basis
(add column, remove column, add/drop table etc). Therefore it is a pain
to
modify business logic layer+business data layer after you for example
added a
column to a database. Additionally you have to recompile after every
change
and bring a server down. Therefore is there a way to bypass re-compilation
process?
I am looking for possibility of making DYNAMIC (or Flexible) classes that
will grab information on tables structure, extract all column names,
types,
column sizes and create objects with properties and CRUD methods to
interfere
with database. Such flexible SQL will be generated on the fly by using
those
classes/componets which will get input data and place it into paramertized
query. Additionally it should be cached on the client and/or on the
server.
