Re: Simple OOP question



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?



.



Relevant Pages

  • Re: Data Access Objects?
    ... DTO has the data to transfer to the Data layer from the Business layer and the DAO has the data to transfer to the Database layer from the Data layer. ...
    (comp.object)
  • Re: Looking for a decent data access architecture to implement
    ... > application so that there is a clean separation between the data access ... > layer, the business layer and the GUI layer. ... > the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Looking for a decent data access architecture to implement
    ... application so that there is a clean separation between the data access ... layer, the business layer and the GUI layer. ... the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: "Business Objects" and the DAL
    ... layer talks to the layer next to it. ... business entity returned that up to the UI for binding to a grid. ... If a database table column names ... Each could be considered a "pattern", ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Size matters to some
    ... The underlying remote database connection ... physical layer is actually managing it all, the logical layer is forced to ... constraints as specified by developers. ... want to validate the information getting written. ...
    (comp.databases.pick)

Quantcast