Simple OOP question

[Nemisis]

HI everyone,

I think i am on the right path but if someone could confirm it, that
would be great.

In my business Layer i have my business object, for this example,
called User.

User has about 50 properties.

To save the user object in my business layer i call the factory and
pass in the object

Dim uf as new userFactory
Dim u as user

uf.save(u)

Now because the DAL and business layer shouldnt care about eachother, i
dont want to pass in a business object into my DAL, so at the moment i
pass in each property as a parameter to my save function in my DAL, is
this right??

'Save function in DAL
Function Save(userid as integer, firstname as string, lastname as
string, ............)

'Save function in BL
Function Save (u as user)
dim dal as new dataservice

dal.save(u.id, u.firstname, u.lastname, ..........)
End Function

Does this make sense? Hopefully i am right, but would like to know
what approach everyone takes. Thanks

[Kevin Spencer]

Yes kevin, i understand that, my save method is actually called Update

(sorry for the confusion), but what you are saying is that i should
pass in a DataRow interface object into the data layer instead of
variables??

That way the data layer would check for the columns on the input'd
tablerow??

No, I never said that you should pass a DataRow to any method in your data
layer. A DataRow doesn't have columns, nor does it contain any information
about the table or database it came from.

Check out the following:

http://www.microsoft.com/downloads/d...displaylang=en

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.
"Nemisis" <da*********@ho tmail.comwrote in message
news:11******** **************@ m73g2000cwd.goo glegroups.com.. .

>
Kevin Spencer wrote:

>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" <da*********@ho tmail.comwrote in message
news:11******* *************** @i42g2000cwa.go oglegroups.com. ..

>
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(st ring query, string tableName,
string connectionStrin g)
{
SqlConnection conn = null;
SqlDataAdapter adapter = null;
DataTable table = new DataTable();

try
{
conn = new SqlConnection(c onnectionstring );
adapter = new SqlDataAdapter( query, conn);
adapter.Fill(ta ble);
if (tableName != "") table.TableName = tableName;
return table;
}
catch (Exception ex)
{
Utilities.Handl eError(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?

Yes kevin, i understand that, my save method is actually called Update
(sorry for the confusion), but what you are saying is that i should
pass in a DataRow interface object into the data layer instead of
variables??

That way the data layer would check for the columns on the input'd
tablerow??