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

[Nemisis]

Sorry if that didnt make sense, but i wondered if the DAL save method
should be

Function Save (id, firstname, lastname)

OR

Function Save(tr As TableRow)

For some reason, i think that it should be the second one, as that
would completely separate the DAL and BOL.

Someone please put me out of my misery! lol

[Laurent Bugnion]

Hi,

Nemisis wrote:

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

That's one possibility. But even then, the BLL has to know something
about the DAL, it must know the signature of the method Save and the
parameters. If the method's signature changes, then you must modify the BLL.

A more OO approach would be to define an interface in the DAL specifying
which properties a IUser must implement. The BLL then implements the
interface in its own User class. Then the DAL Save method is:

public void Save( IUser user )
{
...
}

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[Nemisis]

So it would be better if i wrote a function in the BOL, that converts
the business object to a Data Row, then passed in the datarow into the
Save function within the DAL?

That way the BOL, only needs to know that it needs to pass in a
datarow, which is a generic object??

>>A more OO approach would be to define an interface in the DAL specifying
which properties a IUser must implement. The BLL then implements the
interface in its own User class. Then the DAL Save method is:

Can you give me a lil more detail about this? I am new to .NET 2.0 so
i am picking up things as i go along. Does the above involve
referencing a business object in the DAL? Isnt that what i am trying
to avoid?

[Ray Booysen]

Nemisis wrote:

Sorry if that didnt make sense, but i wondered if the DAL save method
should be

Function Save (id, firstname, lastname)

OR

Function Save(tr As TableRow)

For some reason, i think that it should be the second one, as that
would completely separate the DAL and BOL.

Someone please put me out of my misery! lol

BANG! You're dead. ;)

[Laurent Bugnion]

Hi,

Nemisis wrote:

So it would be better if i wrote a function in the BOL, that converts
the business object to a Data Row, then passed in the datarow into the
Save function within the DAL?

That way the BOL, only needs to know that it needs to pass in a
datarow, which is a generic object??

I don't really like that approach, because it forces your BOL (business
object layer) (what I called BLL before, Business logic layer) to know
that it's handling with a Database oriented store. It makes you add a
"using" statement more in your code file, if you want.

On the other hand, if you define an interface (this is like an abstract
class) in the DAL, then the BOL must only know that interface's
definition, nothing else. For the BOL, it doesn't matter if the data are
saved in a Database, a XML file, or anything else. You could easily swap
the DAL with another implementation without having to change your BOL code.

>>A more OO approach would be to define an interface in the DAL specifying
which properties a IUser must implement. The BLL then implements the
interface in its own User class. Then the DAL Save method is:

Can you give me a lil more detail about this? I am new to .NET 2.0 so
i am picking up things as i go along. Does the above involve
referencing a business object in the DAL? Isnt that what i am trying
to avoid?

No, the DAL defines an interface, for example:

public interface IUser
{
public string Name
{
get;
}
}

This specifies that the implementation of IUser must define a "getter"
property named "Name". This is a contract between the DAL and whoever
wants to use the "Save" method.

The save method becomes:

public void Save( IUser user )
{
...
myName = user.Name;
}

Since IUser is known, the DAL knows that it will have a "Name" property.

Then, the BOL accepts the contract by implementing the following:

public class MyUser : IUser
{
public override string Name
{
get
{
return m_Name;
}
}
}

and then:

MyUser user = new MyUser( "USER1" );
DAL.Save( user );

Note that the call to the Save method is successful, because the "user"
variable is of type MyUser, but also IUser. It's polymorphismus, the
same object has two "shapes". It fulfills the contract.

Note however that full OO is not always the best way, especially when it
comes to efficiency and speed.

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[Kevin Spencer]

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.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.
"Nemisis" <da*********@hotmail.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...

So it would be better if i wrote a function in the BOL, that converts
the business object to a Data Row, then passed in the datarow into the
Save function within the DAL?

That way the BOL, only needs to know that it needs to pass in a
datarow, which is a generic object??

>>>A more OO approach would be to define an interface in the DAL specifying
which properties a IUser must implement. The BLL then implements the
interface in its own User class. Then the DAL Save method is:

Can you give me a lil more detail about this? I am new to .NET 2.0 so
i am picking up things as i go along. Does the above involve
referencing a business object in the DAL? Isnt that what i am trying
to avoid?

[Nemisis]

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?

[Kevin Spencer]

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*********@hotmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.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(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?

[Nemisis]

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*********@hotmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.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(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?

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??

[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*********@hotmail.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.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*********@hotmail.comwrote in message
news:11**********************@i42g2000cwa.googleg roups.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(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?

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??