Re: Simple OOP question
- From: "Kevin Spencer" <uce@xxxxxxx>
- Date: Thu, 24 Aug 2006 12:41:22 -0400
The second method you posted depends upon knowing what fields are in the
table, what table you're updating, and what the database used is. Therefore,
it's not a good Data Layer method. It can only be used with the Business
layer for that project. You want to create generic functions in the Data
layer that perform database operations only. For example, there is no
database operation called "Save." Database operations include things like
SELECT, UPDATE, DELETE, CREATE TABLE, etc. In the case of "Save" you're
talking about doing an UPDATE.
Now, if you want to have a "Save" method in your business class that uses a
generic UPDATE method in your Data layer, that's fine.
--
HTH,
Kevin Spencer
Microsoft MVP
Chicken Salad Surgery
It takes a tough man to make a tender chicken salad.
"Nemisis" <darrens2005@xxxxxxxxxxx> wrote in message
news:1156426660.592466.144660@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Kevin Spencer wrote:
The business layer is always going to have to know something about the
data
layer, just as the UI layer must know something about the business layer.
It
is the data layer which should not need to know anything about the
business
layer (so you can use it in multiple solutions). The business layer must
know the data layers API in order to use it.
Therefore, the data layer function should take raw data and be able to
perform any database operation with it, without knowing what the data is.
That is, your data layer should contain abstract data functionality that
is
not specific to any database or data store, and present a uniform API to
any
client application.
Here's an example from our in-house data class library:
public static DataTable GetDataTable(string query, string tableName,
string connectionString)
{
SqlConnection conn = null;
SqlDataAdapter adapter = null;
DataTable table = new DataTable();
try
{
conn = new SqlConnection(connectionstring);
adapter = new SqlDataAdapter(query, conn);
adapter.Fill(table);
if (tableName != "") table.TableName = tableName;
return table;
}
catch (Exception ex)
{
Utilities.HandleError(ex);
throw new DataException("Error fetching DataTable", query, cstring,
ex);
}
finally
{
if (conn != null) conn.Dispose();
if (adapter != null) adapter.Dispose();
}
}
This method returns a DataTable, but knows nothing about the table, the
data, or the database being used. The business layer knows the signature
of
this method, and can call it whenever it needs a DataTable of data
fetched
from its data store.
Kevin,
I am confident about the load methods as i load all my data to the BLL
using datasets, but it is more on saving methods from the BLL to DAL.
Can you explain a lil more on this?
I would like to know whether the DAL save method, should either accept
a DataRow (IDataRow), or a series of parameters, thus.
Save(tr as TableRow)
Or
Save(id as integer, name as string, ref as string, ............)
At current i am doing it the second way, but am feeling that maybe i
should be doing it the first way. Any views?
.
- Follow-Ups:
- Re: Simple OOP question
- From: Nemisis
- Re: Simple OOP question
- References:
- Simple OOP question
- From: Nemisis
- Re: Simple OOP question
- From: Laurent Bugnion
- Re: Simple OOP question
- From: Nemisis
- Re: Simple OOP question
- From: Kevin Spencer
- Re: Simple OOP question
- From: Nemisis
- Simple OOP question
- Prev by Date: Re: Populating Controls - Form Load Dynamically
- Next by Date: Re: Simple OOP question
- Previous by thread: Re: Simple OOP question
- Next by thread: Re: Simple OOP question
- Index(es):
Relevant Pages
|