Hi Peter,
A Database class should do one thing and do it well: Interact with both
business classes (as a server) and with a database (as a client). It is the
intermediary between the business classes and the database itself (wherever
and whatever the database may be). The .Net Framework has some really keen
classes for working with data, such as the DataSet, DataTable, DataAdapter,
DataReader, and so on. These classes present a uniform interface to any
business class that needs data. So, the Database class functions like a
"Universal Translator," an "ambassador," if you will, between the business
classes and the Database itself.
The classic 3-tier application model is the basis for all good multi-tiered
application models (which are generally sub-divided in one way or another).
It represents the core levels of the application. An application is a tool
that enables humans to work with data. A Database is a container for data,
and contains functionality for working with the data, inserting, updating,
deleting, sorting, indexing, querying, etc. It presents the data in it in
the form of an in-memory cursor, in a proprietry format that is unique to
the database product itself.
Technologies like the SQL language, OLE DB, the native SQL Provider, ODBC,
etc., present a "driver-oriented" and more universal means for applications
to interact with databases. However, they are too universal to be useful to
a business class, which may need to change the data source from time to
time, from, for example, Access to SQL Server.
The Data Layer, or Data Tier of an application is developed with the same
programming technology (in this case, the .Net Framework) as the business
classes. It also has the capability of working with a variety of data
sources. It's purpose is to present to the application as a whole an
interface to the underlying data store, whatever that may be. If the
database changes, the Database class can still work with it. Yet, on the
client end, it will present the data in the same format regardless, in this
case, as DataSets, DataTables, DataReaders, etc. If it is well-designed, it
can serve many types of business classes. It knows nothing about the data it
is serving; it only follows instructions from the Business classes
themselves, which know what the data is, and what they want to do with it.
The Business tier is called this because it contains the "business rules"
for working with the specific data it is designed to work with. It contains
all the logic for creating new records, updating records, munging data in a
variety of ways, and exposes an object-oriented API (programming interface)
that is easier for client classes (and developers) to work with, than, for
example, a table, or the results of a JOIN query.
You have, for example, a PurchaseOrder class. Now, in the database, it is
nothing but a row in a table, or a JOIN query result set, with a bunch of
columns in it. But you expose it as if it were a real Purchase Order. The
PurchaseOrder class can do things like look up Inventory (using the
Inventory class), perform calculations on the data, perhaps present a string
representation of a Purchase Order, an XML document, or even present a
stream for printing, who knows? So, the PurchaseOrder business class
encapsulates all of the functionality for working with a Purchase Order, as
well as the data.
On the top tier, you have the User Interface layer. It is important to keep
this separate from the Business layer, as you may want to expose the data in
a different User Interface at some point in the future. So, the Interface
classes don't do the munging of the data. They simply provide a
user-friendly interface ot the user, and a connection on the back end to the
business classes they work with. Again, the business classes actually do all
the work, each "minding its own business."
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
"Peter Kirk" <pk@alpha-solutions.dk> wrote in message
news:e5*************@tk2msftngp13.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> skrev i en meddelelse
news:uX**************@tk2msftngp13.phx.gbl...I can see a few problems with your design.
First, one important principle of OOP is that a busines class should
"mind its own business." A Database class should be agnostic of business
classes that it may interact with. You just might want to use that
Database class with another project, and if you design it well, you can.
What exactly do you mean by "business class" and "database class"? For me
a "business" class might represent some data used in the particular
application, for example an "Employee" class. A "database" class interacts
with a database on behalf of the application, retrieving or storing
business classes.
This is maybe an incorrect way to view it?
Do you mean that a database class is a generic class you write to interact
with a generic database? That would be very hard to write, wouldn't it?
What objects does it return from a query? A Hashtable with column names
and values? An IList of "Database row" objects? Where does the database
class receive knowledge of what query to execute?
The database classes I have written usually do know the "business"
classes. For example I might have a "FetchEmployee" method in my database
class. This method knows the query to execute and instantiates and returns
a known type of object (for example an instance of IEmployee).
Is this bad design? How could it be done better?
So, let's get down to principles here. The purpose of a Database class is
to provide data to business classes.
Do you mean that a business class should query the database (via the
Database class) to populate itself with data?
Peter