Classes concepts

[Josema]

Hi to all,

actually im a newbie in the OOP and i would like to know if this way of
using clases its a best way (logical, and a good way)

Lets imagine that i have a data base with departments (depid, depname)

if i make the class

public class department
{
private int id;
private string name;

public int ID
{
get{return id;}
set{id=value;}
}
public string Name
{
get{return name;}
set{name=value;}
}
}

like which I want is to create a class for each department i make another
class:

public class departments
{
private department[] ListofDepartments;

public departments()
{
//Imagine that i have a datatable with all the query (select * from
departments)
ListofDepartments=new departament[datatable.rows.count];
//Imagine that i make a loop = for i=0 to rows into the datatable
ListofDepartments[i]=new Department()
//assing into the ListofDepartments[i].ID and Name the values of the
datatable
}
}

Its this a good way to create this?,

Could you put me an example about wich methods could be implemented in the
department class (the first)
Thanks a lot
Regards.
Josema

[Nicholas Paldino [.NET/C# MVP]]

Josema,

For what you are trying to do, I think there are some better ways to do
it. First, the class name should be Department, and not department.

For the collection class, I would derive from CollectionBase, and in
..NET 2.0, I would use the List<T> class to represent the collection of
department.

However, I wouldn't even do this at all. In the end, I would use typed
data sets set up in the IDE and use those. It would provide the easiest
access for the data, as well as offering that grouping into collections that
you need.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Josema" <Je******@ocu.org> wrote in message
news:80**********************************@microsof t.com...

Hi to all,

actually im a newbie in the OOP and i would like to know if this way of
using clases its a best way (logical, and a good way)

Lets imagine that i have a data base with departments (depid, depname)

if i make the class

public class department
{
private int id;
private string name;

public int ID
{
get{return id;}
set{id=value;}
}
public string Name
{
get{return name;}
set{name=value;}
}
}

like which I want is to create a class for each department i make another
class:

public class departments
{
private department[] ListofDepartments;

public departments()
{
//Imagine that i have a datatable with all the query (select * from
departments)
ListofDepartments=new departament[datatable.rows.count];
//Imagine that i make a loop = for i=0 to rows into the datatable
ListofDepartments[i]=new Department()
//assing into the ListofDepartments[i].ID and Name the values of the
datatable
}
}

Its this a good way to create this?,

Could you put me an example about wich methods could be implemented in the
department class (the first)
Thanks a lot
Regards.
Josema

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

public class department
{
private int id;
private string name;

public int ID
{
get{return id;}
set{id=value;}
}
public string Name
{
get{return name;}
set{name=value;}
}
}
So far so good. Only that you should define a constructor, otherwise you may
use one get property on an non initializad value ( exception)
like which I want is to create a class for each department i make another
class:
Nop, you want to create an INSTANCE OF A CLASS , not a class, they are
different things !!!
public class departments
{
private department[] ListofDepartments;

public departments()
{
//Imagine that i have a datatable with all the query (select * from
departments)
ListofDepartments=new departament[datatable.rows.count];
//Imagine that i make a loop = for i=0 to rows into the datatable
ListofDepartments[i]=new Department()
//assing into the ListofDepartments[i].ID and Name the values of the
datatable
}
}

Its this a good way to create this?,
It works, but IMO it's not the best, if you want a collection of a
determined typed, or in other words a Strong Typed Collection you should
inherit from CollectionBase. take a look at it in the MSDN
Could you put me an example about wich methods could be implemented in the
department class (the first)

It depends of what you want to do with it, what operations are you gonna to
perform based on Department , maybe a GetAssociatesList() or Chairman , etc

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Josema]

Okay, i will take a look for this Class

Thnx Nicholas.
"Nicholas Paldino [.NET/C# MVP]" wrote:

Josema,

For what you are trying to do, I think there are some better ways to do
it. First, the class name should be Department, and not department.

For the collection class, I would derive from CollectionBase, and in
..NET 2.0, I would use the List<T> class to represent the collection of
department.

However, I wouldn't even do this at all. In the end, I would use typed
data sets set up in the IDE and use those. It would provide the easiest
access for the data, as well as offering that grouping into collections that
you need.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Josema" <Je******@ocu.org> wrote in message
news:80**********************************@microsof t.com...

Hi to all,

actually im a newbie in the OOP and i would like to know if this way of
using clases its a best way (logical, and a good way)

Lets imagine that i have a data base with departments (depid, depname)

if i make the class

public class department
{
private int id;
private string name;

public int ID
{
get{return id;}
set{id=value;}
}
public string Name
{
get{return name;}
set{name=value;}
}
}

like which I want is to create a class for each department i make another
class:

public class departments
{
private department[] ListofDepartments;

public departments()
{
//Imagine that i have a datatable with all the query (select * from
departments)
ListofDepartments=new departament[datatable.rows.count];
//Imagine that i make a loop = for i=0 to rows into the datatable
ListofDepartments[i]=new Department()
//assing into the ListofDepartments[i].ID and Name the values of the
datatable
}
}

Its this a good way to create this?,

Could you put me an example about wich methods could be implemented in the
department class (the first)
Thanks a lot
Regards.
Josema

[Josema]

Okay, then if i create mi collection of departments deriving from
Collectionbase
and to fill the collection i can using one or two constructors, but if i
want to remove or update a department from the database for instance:

1) may i include these methods in Department class or in Departments
class(collectionbase)?

2) I supposed that remove a Department it supposes remove from the
collection and then from the database, its correct?
"Ignacio Machin ( .NET/ C# MVP )" wrote:

Hi,

public class department
{
private int id;
private string name;

public int ID
{
get{return id;}
set{id=value;}
}
public string Name
{
get{return name;}
set{name=value;}
}
}

So far so good. Only that you should define a constructor, otherwise you may
use one get property on an non initializad value ( exception)

like which I want is to create a class for each department i make another
class:

Nop, you want to create an INSTANCE OF A CLASS , not a class, they are
different things !!!

public class departments
{
private department[] ListofDepartments;

public departments()
{
//Imagine that i have a datatable with all the query (select * from
departments)
ListofDepartments=new departament[datatable.rows.count];
//Imagine that i make a loop = for i=0 to rows into the datatable
ListofDepartments[i]=new Department()
//assing into the ListofDepartments[i].ID and Name the values of the
datatable
}
}

Its this a good way to create this?,

It works, but IMO it's not the best, if you want a collection of a
determined typed, or in other words a Strong Typed Collection you should
inherit from CollectionBase. take a look at it in the MSDN

Could you put me an example about wich methods could be implemented in the
department class (the first)

It depends of what you want to do with it, what operations are you gonna to
perform based on Department , maybe a GetAssociatesList() or Chairman , etc

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

the Department class should provide methods to Add/Save/Remove a department
from the DB , it also need a method to load them

This is a possible solution

creating a static property in the Department class that return the
collection of departments instances.

class Department{

static DepartmentCollection departments;
public DepartmentCollection DepartmentList{ get{ departments}}

}

of course this is useless without a LoadList method:

static Department() { LoadList(); }
static void LoadList()
{
departments = new DepartmentCollection ()
//load it from the DB and add to the list
}

Now you have the basic structure, you can implement a Remove instance method
for example

public Remove()
{
//remove from the db
//remove from the list
departments.Remove( this);
}
Hope this give you an idea/.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Josema" <Je******@ocu.org> wrote in message
news:DD**********************************@microsof t.com...

Okay, then if i create mi collection of departments deriving from
Collectionbase
and to fill the collection i can using one or two constructors, but if i
want to remove or update a department from the database for instance:

1) may i include these methods in Department class or in Departments
class(collectionbase)?

2) I supposed that remove a Department it supposes remove from the
collection and then from the database, its correct?
"Ignacio Machin ( .NET/ C# MVP )" wrote:

Hi,

public class department
{
private int id;
private string name;

public int ID
{
get{return id;}
set{id=value;}
}
public string Name
{
get{return name;}
set{name=value;}
}
}

So far so good. Only that you should define a constructor, otherwise you may use one get property on an non initializad value ( exception)

like which I want is to create a class for each department i make another class:

Nop, you want to create an INSTANCE OF A CLASS , not a class, they are
different things !!!

public class departments
{
private department[] ListofDepartments;

public departments()
{
//Imagine that i have a datatable with all the query (select * from departments)
ListofDepartments=new departament[datatable.rows.count];
//Imagine that i make a loop = for i=0 to rows into the datatable
ListofDepartments[i]=new Department()
//assing into the ListofDepartments[i].ID and Name the values of the datatable
}
}

Its this a good way to create this?,

It works, but IMO it's not the best, if you want a collection of a
determined typed, or in other words a Strong Typed Collection you should
inherit from CollectionBase. take a look at it in the MSDN

Could you put me an example about wich methods could be implemented in the department class (the first)

It depends of what you want to do with it, what operations are you gonna to perform based on Department , maybe a GetAssociatesList() or Chairman , etc
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[José María Estrade Nieto]

Thanks, that was very useful, now i understand better.

Regards.
Josema.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Nick Malik]

No offense, Ignacio, but didn't you just reinvent some of the capabilities
of the DataSet object?

What's the point?

--- Nick

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2***************@TK2MSFTNGP11.phx.gbl...

Hi,

the Department class should provide methods to Add/Save/Remove a department from the DB , it also need a method to load them

This is a possible solution

creating a static property in the Department class that return the
collection of departments instances.

class Department{

static DepartmentCollection departments;
public DepartmentCollection DepartmentList{ get{ departments}}

}

of course this is useless without a LoadList method:

static Department() { LoadList(); }
static void LoadList()
{
departments = new DepartmentCollection ()
//load it from the DB and add to the list
}

Now you have the basic structure, you can implement a Remove instance method for example

public Remove()
{
//remove from the db
//remove from the list
departments.Remove( this);
}
Hope this give you an idea/.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Josema" <Je******@ocu.org> wrote in message
news:DD**********************************@microsof t.com...

Okay, then if i create mi collection of departments deriving from
Collectionbase
and to fill the collection i can using one or two constructors, but if i
want to remove or update a department from the database for instance:

1) may i include these methods in Department class or in Departments
class(collectionbase)?

2) I supposed that remove a Department it supposes remove from the
collection and then from the database, its correct?
"Ignacio Machin ( .NET/ C# MVP )" wrote:

Hi,
> public class department
> {
> private int id;
> private string name;
>
> public int ID
> {
> get{return id;}
> set{id=value;}
> }
> public string Name
> {
> get{return name;}
> set{name=value;}
> }
> }

So far so good. Only that you should define a constructor, otherwise you

may

use one get property on an non initializad value ( exception)

> like which I want is to create a class for each department i make another > class:

Nop, you want to create an INSTANCE OF A CLASS , not a class, they

are different things !!!

> public class departments
> {
> private department[] ListofDepartments;
>
> public departments()
> {
> //Imagine that i have a datatable with all the query (select *

from > departments)
> ListofDepartments=new departament[datatable.rows.count];
> //Imagine that i make a loop = for i=0 to rows into the datatable > ListofDepartments[i]=new Department()
> //assing into the ListofDepartments[i].ID and Name the values of the

> datatable
> }
> }
>
> Its this a good way to create this?,

It works, but IMO it's not the best, if you want a collection of a
determined typed, or in other words a Strong Typed Collection you

should inherit from CollectionBase. take a look at it in the MSDN

> Could you put me an example about wich methods could be implemented

in the > department class (the first)

It depends of what you want to do with it, what operations are you

gonna

to perform based on Department , maybe a GetAssociatesList() or Chairman

,

etc
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Nick,

A dataset is a data struct WITHOUT operations over that data , one of the
core concepts in OOP is that the data & operation related to it lives
together, it's called encapsulation.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:yGe6d.123925$MQ5.57078@attbi_s52...

No offense, Ignacio, but didn't you just reinvent some of the capabilities
of the DataSet object?

What's the point?

--- Nick

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in message news:%2***************@TK2MSFTNGP11.phx.gbl...

Hi,

the Department class should provide methods to Add/Save/Remove a department

from the DB , it also need a method to load them

This is a possible solution

creating a static property in the Department class that return the
collection of departments instances.

class Department{

static DepartmentCollection departments;
public DepartmentCollection DepartmentList{ get{ departments}}

}

of course this is useless without a LoadList method:

static Department() { LoadList(); }
static void LoadList()
{
departments = new DepartmentCollection ()
//load it from the DB and add to the list
}

Now you have the basic structure, you can implement a Remove instance

method

for example

public Remove()
{
//remove from the db
//remove from the list
departments.Remove( this);
}
Hope this give you an idea/.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Josema" <Je******@ocu.org> wrote in message
news:DD**********************************@microsof t.com...

Okay, then if i create mi collection of departments deriving from
Collectionbase
and to fill the collection i can using one or two constructors, but if i want to remove or update a department from the database for instance:

1) may i include these methods in Department class or in Departments
class(collectionbase)?

2) I supposed that remove a Department it supposes remove from the
collection and then from the database, its correct?
"Ignacio Machin ( .NET/ C# MVP )" wrote:

> Hi,
>
>
> > public class department
> > {
> > private int id;
> > private string name;
> >
> > public int ID
> > {
> > get{return id;}
> > set{id=value;}
> > }
> > public string Name
> > {
> > get{return name;}
> > set{name=value;}
> > }
> > }
>
> So far so good. Only that you should define a constructor, otherwise you

may

> use one get property on an non initializad value ( exception)
>
> > like which I want is to create a class for each department i make

another

> > class:
>
> Nop, you want to create an INSTANCE OF A CLASS , not a class, they are > different things !!!
>
> > public class departments
> > {
> > private department[] ListofDepartments;
> >
> > public departments()
> > {
> > //Imagine that i have a datatable with all the query (select

* from

> > departments)
> > ListofDepartments=new departament[datatable.rows.count];
> > //Imagine that i make a loop = for i=0 to rows into the

datatable > > ListofDepartments[i]=new Department()
> > //assing into the ListofDepartments[i].ID and Name the

values of

the

> > datatable
> > }
> > }
> >
> > Its this a good way to create this?,
>
> It works, but IMO it's not the best, if you want a collection of a
> determined typed, or in other words a Strong Typed Collection you

should > inherit from CollectionBase. take a look at it in the MSDN
>
> > Could you put me an example about wich methods could be

implemented in

the

> > department class (the first)
>
> It depends of what you want to do with it, what operations are you

gonna

to

> perform based on Department , maybe a GetAssociatesList() or

Chairman ,

etc

>
> Cheers,
>
> --
> Ignacio Machin,
> ignacio.machin AT dot.state.fl.us
> Florida Department Of Transportation
>
>
>
>

[Nick Malik]

Hi Ignacio,

OK, fair point. (I know what encapsulation is).

However, in a middle tier, we often want to seperate the data structure from
the database operations that map that data structure to a particular
repository. This is especially true if we use the data structure to
"communicate" between tiers. With the Dataset, we get a comprehensive,
serializable data structure, and with the Data Adapter, we get the
operations. The Data adapter provides the access to SQL.

While your suggestion is in keeping with some common approaches to middle
tier development, I fail to see how it makes sense to do it this way given
the rich functionality of the Data Adapter.

--- Nick

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:u3**************@TK2MSFTNGP12.phx.gbl...

Hi Nick,

A dataset is a data struct WITHOUT operations over that data , one of the core concepts in OOP is that the data & operation related to it lives
together, it's called encapsulation.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:yGe6d.123925$MQ5.57078@attbi_s52...

No offense, Ignacio, but didn't you just reinvent some of the capabilities

of the DataSet object?

What's the point?

--- Nick

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote

in message news:%2***************@TK2MSFTNGP11.phx.gbl...

Hi,

the Department class should provide methods to Add/Save/Remove a

department

from the DB , it also need a method to load them

This is a possible solution

creating a static property in the Department class that return the
collection of departments instances.

class Department{

static DepartmentCollection departments;
public DepartmentCollection DepartmentList{ get{ departments}}

}

of course this is useless without a LoadList method:

static Department() { LoadList(); }
static void LoadList()
{
departments = new DepartmentCollection ()
//load it from the DB and add to the list
}

Now you have the basic structure, you can implement a Remove instance

method

for example

public Remove()
{
//remove from the db
//remove from the list
departments.Remove( this);
}
Hope this give you an idea/.
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Josema" <Je******@ocu.org> wrote in message
news:DD**********************************@microsof t.com...
> Okay, then if i create mi collection of departments deriving from
> Collectionbase
> and to fill the collection i can using one or two constructors, but if i > want to remove or update a department from the database for

instance: >
> 1) may i include these methods in Department class or in Departments
> class(collectionbase)?
>
> 2) I supposed that remove a Department it supposes remove from the
> collection and then from the database, its correct?
>
>
> "Ignacio Machin ( .NET/ C# MVP )" wrote:
>
> > Hi,
> >
> >
> > > public class department
> > > {
> > > private int id;
> > > private string name;
> > >
> > > public int ID
> > > {
> > > get{return id;}
> > > set{id=value;}
> > > }
> > > public string Name
> > > {
> > > get{return name;}
> > > set{name=value;}
> > > }
> > > }
> >
> > So far so good. Only that you should define a constructor, otherwise

you

may
> > use one get property on an non initializad value ( exception)
> >
> > > like which I want is to create a class for each department i

make another
> > > class:
> >
> > Nop, you want to create an INSTANCE OF A CLASS , not a class,

they are

> > different things !!!
> >
> > > public class departments
> > > {
> > > private department[] ListofDepartments;
> > >
> > > public departments()
> > > {
> > > //Imagine that i have a datatable with all the query

(select * from
> > > departments)
> > > ListofDepartments=new departament[datatable.rows.count];
> > > //Imagine that i make a loop = for i=0 to rows into the

datatable

> > > ListofDepartments[i]=new Department()
> > > //assing into the ListofDepartments[i].ID and Name the

values

of

the
> > > datatable
> > > }
> > > }
> > >
> > > Its this a good way to create this?,
> >
> > It works, but IMO it's not the best, if you want a collection of a
> > determined typed, or in other words a Strong Typed Collection you

should

> > inherit from CollectionBase. take a look at it in the MSDN
> >
> > > Could you put me an example about wich methods could be

implemented

in

the
> > > department class (the first)
> >
> > It depends of what you want to do with it, what operations are you

gonna

to
> > perform based on Department , maybe a GetAssociatesList() or

Chairman

,

etc
> >
> > Cheers,
> >
> > --
> > Ignacio Machin,
> > ignacio.machin AT dot.state.fl.us
> > Florida Department Of Transportation
> >
> >
> >
> >

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Nick,
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:fbz6d.137803$D%.71616@attbi_s51...

Hi Ignacio,

OK, fair point. (I know what encapsulation is).

However, in a middle tier, we often want to seperate the data structure from the database operations that map that data structure to a particular
repository. This is especially true if we use the data structure to
"communicate" between tiers. With the Dataset, we get a comprehensive,
serializable data structure, and with the Data Adapter, we get the
operations. The Data adapter provides the access to SQL.
You can separate the data access from the business layer, you can have a
backend DB layer that receive an instance of the type and do the DBs
operations, in this way the business object don;t need to have knowledge of
the db. The method Save() of the business class just build a ICommand and
pass it to the DB layer, another way of doing this is that the db layer
provide a method that receive as parameter a Business class and save it.

I think that you are seeing it in a procedural way, you are separating the
data from the operations to perform over it.

Even so you are not thinking in the business rules of the system, how will
you implement them? you will need to have methods in some class that perform
operation over that data after all.
While your suggestion is in keeping with some common approaches to middle
tier development, I fail to see how it makes sense to do it this way given
the rich functionality of the Data Adapter.

This has nothing to do with that. A DataAdapter is just the way to
communicate with the DB, a helper, it has nothing to do with the
implementation of business rules and relationship among the differents
entities ( classes in the business layer and tables in the db ) than make
the system work as expected.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Nick Malik]

Hi Ignacio,

Thanks for engaging me in discussion. I learn by asking.

<<thread trimmed for length... hopefully not meaning>>

However, in a middle tier, we often want to seperate the data structure from

the database operations that map that data structure to a particular
repository. You can separate the data access from the business layer, you can have a
backend DB layer that receive an instance of the type and do the DBs
operations, in this way the business object don;t need to have knowledge of the db. The method Save() of the business class just build a ICommand and
pass it to the DB layer, another way of doing this is that the db layer
provide a method that receive as parameter a Business class and save it.

True, you could do this... a good example of using the Command pattern.
It's a good idea. My argument is not against these clever designs...
I believe that they are not necessary. In your prior discussion with
Josema,
you queried the data in DataRows and then promptly moved the data into
object variables in the business layer.

I believe that any clarity you gain is far outweighed by the time you spend
moving data from one representation to another. (This is often called
Object-Relational Impedence: the effort necessary to "map" the
representation of data from object-oriented to relational and back.)
I think that you are seeing it in a procedural way, you are separating the data from the operations to perform over it.

This is a common OO pattern. Take a look at the Bridge pattern
(http://c2.com/cgi/wiki?BridgePattern). Sure, you can do this in a
procedural language as well, but it is more powerful when done in an OO
language, and is commonly used in both Java and .Net.
Even so you are not thinking in the business rules of the system, how will you implement them? you will need to have methods in some class that perform operation over that data after all.
Ah, but I am thinking of the business rules. You see, the overwheming
majority of folks who create nice layers of objects between their U/I and
their data layer haven't the slightest clue WHAT TO PUT THERE! Those of us
who understand the distinction between validation and a business rule have
failed to communicate clearly the value of the business layer, except as an
abstraction for the database. I would charge that the abstraction of the
database should be done as part of a Bridge pattern in the data access
layer, and that data should come "up" into the business layer in a
serializable, non-database-specific representation (like a DataRow or a
DataSet).

We appear not to be far apart on that. However, I do not believe that it
makes a lot of sense to write miles of code to move data from one
representation to another. The data is in a DataRow. Leave it there. You
can either encapsulate the data row in a "Department" object (to use
Josema's example), providing accessors to it (which I believe is Still
overkill), or you can use the DataAdapter itself to map data column names,
and you can use the DataRow or DataSet all the way from the U/I, through the
B/L, to the DAL, without changing representations.

Business rules would be implemented by creating an object that inherits from
a B/L base class that you can define. All object walk through this type of
B/L object in order to get to the DAL, and the base class defines how to
call the DAL from the B/L code. This leaves the B/L objects to actually
implement rules... and you know what I'll bet? I'll bet that 90% of the B/L
objects created have no rules at all, and can use the base class to access
the underlying data set.

While your suggestion is in keeping with some common approaches to

middle tier development, I fail to see how it makes sense to do it this way given the rich functionality of the Data Adapter.

This has nothing to do with that. A DataAdapter is just the way to
communicate with the DB, a helper, it has nothing to do with the
implementation of business rules and relationship among the differents
entities ( classes in the business layer and tables in the db ) than make
the system work as expected.

You are right that the DataAdapter has nothing to do with implementation of
business rules. I don't mean to imply that it does. However, the designs
that you were demonstrating for Josema were so intent on recreating the
functionality of the Data Adapter, that your code didn't either, and that's
what triggered my query. I would suggest that if we all were to
WriteLessCode and CreateMoreValue, we'd avoid designs in the middle tier
that do little more than assign data columns from one representation to
another.

Thanks again for being willing to discuss this with me. I value your
opinion.

--- Nick Malik
Applications Architect
http://weblogs.asp.net/nickmalik

[Raymond Lewallen]

I think both Nick and Ignacio have excellent points and both provide very
clever and efficient ways to accomplish similar goals. I follow the
approach that Igancio takes with his implementations and movement of data
from the database to the gui via DA and BL layers. One reason for doing
this, and probably the biggest reason, is that the GUI supplied information
from the user is normally not the way its stored in the database and that
must go through actual large numbers of business logic validations. When
looking at Nick's views on providing the same medium for the information all
up through the layers, this, in my opinion, doesn't work for those
applications that actually do have vast amounts of business logic. Nick
stated in one post that he bets that 90% of the B/L objects created have no
rules at all and are used for accessing the underlying dataset, hence his
paragraph on the base class. I think that is a misuse and misclassification
of what business logic is meant to be if that is the only purpose it is
serving for your application. In the application I work on, our business
logic layer is almost 3 times more lines of code that both the data access
layer and gui layers combined, because it does all the thinking. It takes
care of conversion processes of data, data manipulation to conform to a
standard, validating the data against guidelines that require the data to
meet certain criteria and be in a certain format and so many other things.
Lots of times those formats of data storage are not the same formats in
which you want to supply to your user interface. Our data access layers
does nothing more than take what its given and put in the database (and of
course, pull the information out when requested). The GUI does nothing more
than take the data its given from business rules and provide that
information to the user, then give it back when/if it changes.

Naturally, each application is different, and the one I work on is certainly
no exception, as it is very specialized with thousands of pages of Federal
Rules and Regulations to which it must adhere and validate data against.

Thank you both, Nick and Ignacio, for your opinions and for sharing your
conversation on a thread. Its great reading posts from intelligent and
knowledgable developers.

--

Raymond Lewallen
http://rlewallen.blogspot.com

[Nick Malik]

Hello Raymond,

Thanks for your contribution. My comments are embedded.

"Raymond Lewallen" <Ra******************@nospam.faa.gov> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

I follow the approach that Igancio takes with his implementations and movement of data from the database to the gui via DA and BL layers. One reason for doing
this, and probably the biggest reason, is that the GUI supplied information from the user is normally not the way its stored in the database and that
must go through actual large numbers of business logic validations.
You are probably not typical in your applications complexity. However, in
your case,
it certainly makes sense to have an extended business layer, with a great
deal of
objects. You have a lot to encapsulate.
When
looking at Nick's views on providing the same medium for the information all up through the layers, this, in my opinion, doesn't work for those
applications that actually do have vast amounts of business logic.
Agreed. My suggestion is not applicable to all applications.
Nick stated in one post that he bets that 90% of the B/L objects created have no rules at all and are used for accessing the underlying dataset, hence his
paragraph on the base class. I think that is a misuse and misclassification of what business logic is meant to be if that is the only purpose it is
serving for your application.
Ah, but data coming through the B/L isn't always coming through for
the purpose of serving the business logic. Frequently, the U/I needs to
populate a drop-down box, or needs to allow a user to search from among
a large list of possibilities before associating a new record... (Example:
creating a purchase order: search for the customer from the list of
customers... associate the customer id with the purchase order).

There is nearly no business logic on the lookup from the customer table
in this example. Similarly, look up from the list of US States, for
some e-commerce apps, the state list is simply a draw from the db.

I would suggest that the words "misuse" or "misclassification" are
stronger terms than you may want to apply to apps that legitimately
need this data, but do not need to apply rules to it.

I would also maintain that, if you took it as a
percentage, over 40% of all business objects are provided
solely to feed lookup tables, and another 50% (in averate
IT applications) are doing "dumb" inserts and queries, where
there is little or no manipulation of the data other
than assigning the primary key. (The numbers are not scientific.
They are about as good as most "effort estimates" that managers
routinely ask developers to give... based on experience).

The other 10% of business objects may have a great deal of
logic under them. These object can have dozens of other classes servicing
that logic, encapsulating complexity and points where change will occur.

If your business layer services thirty business objects, and you have
serious
logic under three of those objects, you have the same percentage that I have
seen. If that logic requires the creation of 20 more classes to manage,
that doesn't change my assertion. I suspect that this is NOT the
case with your application, but I assert that this is commonly
the case with the vast majority of applications.
In the application I work on, our business
logic layer is almost 3 times more lines of code that both the data access
layer and gui layers combined, because it does all the thinking. It takes
care of conversion processes of data, data manipulation to conform to a
standard, validating the data against guidelines that require the data to
meet certain criteria and be in a certain format and so many other things.
I wouldn't choose to argue the point. Your app is yours, and you've already
done the work. My original concern was that we were asking the original
poster to do the same work without discovering if his app would need it,
as yours does. Not all problems should be solved the exact same way.
Lots of times those formats of data storage are not the same formats in
which you want to supply to your user interface. Our data access layers
does nothing more than take what its given and put in the database (and of
course, pull the information out when requested). The GUI does nothing more than take the data its given from business rules and provide that
information to the user, then give it back when/if it changes.
Sounds very well architected. Cudos.

Naturally, each application is different, and the one I work on is certainly no exception, as it is very specialized with thousands of pages of Federal
Rules and Regulations to which it must adhere and validate data against.
Sounds like a HIPAA app. I did HIPAA work for two and a half years.
Very detailed regulations. I understand the complexity that apps of this
type come up against. I also worked on the sidelines of an app for the
my state's Dept of Agriculture that was to assist with collecting
inspection data for large grain shipments. The regs on that one were
fairly sizable as well.

Thank you both, Nick and Ignacio, for your opinions and for sharing your
conversation on a thread. Its great reading posts from intelligent and
knowledgable developers.

And thanks again for your contribution.

--- Nick

[Raymond Lewallen]

Nick,

Thanks for your response. If I don't make any sense this morning, its
because I'm still waiting on the coffee to finish brewing.

Sounds like a HIPAA app. I did HIPAA work for two and a half years.
Very detailed regulations. I understand the complexity that apps of this
type come up against. I also worked on the sidelines of an app for the
my state's Dept of Agriculture that was to assist with collecting
inspection data for large grain shipments. The regs on that one were
fairly sizable as well.
Actually, I work for the Federal Aviation Administration, and its a
classified application. I wish I could elaborate on it, because its darn
cool! My boss and I are responsible for the interpretation of the
regulations, and I'm the one who converts them to source code and
validations. Right now I've got over 5000 pages, printed front AND back,
single spaced at 8 pt font. :( Needless to say, I spend a lot of time
reading.
Ah, but data coming through the B/L isn't always coming through for
the purpose of serving the business logic. Frequently, the U/I needs to
populate a drop-down box, or needs to allow a user to search from among
a large list of possibilities before associating a new record... (Example:
creating a purchase order: search for the customer from the list of
customers... associate the customer id with the purchase order).
One of my middle-tier layers does nothing but provide lookup tables via
dataviews, but I don't call it a B/L layer. I call it a 2nd layer of the
DAL, really. In my head, just because its a middle-tier layer of the
application, that doesn't mean its B/L, so I refuse to call it as such,
therefore, leaving my B/L layers, as documented and architected by me, to
handle just that, B/L. Lookup table types providing that information simply
don't fit into my definition of B/L. Now, to argue with myself a bit, there
are applicable business rules that can be applied to that data once
retrieved, such as filters on a DataView. In you example above, I would
place the obtaining of the data into a non-B/L middle-tier layer, the
searching/filtering of the data and the association of the customer id with
the PO in a B/L.
There is nearly no business logic on the lookup from the customer table
in this example. Similarly, look up from the list of US States, for
some e-commerce apps, the state list is simply a draw from the db.
As stated above, I don't classify these types of instructions as part of
B/L, but am aware that it is common practice to do so. Am I the only one
who sees it the way I do?
I would suggest that the words "misuse" or "misclassification" are
stronger terms than you may want to apply to apps that legitimately
need this data, but do not need to apply rules to it.
I agree. Those words were too strong to apply to cases of B/L used in this
fashion, as the logic does serve a legitimate purpose for being placed
there.

I would also maintain that, if you took it as a
percentage, over 40% of all business objects are provided
solely to feed lookup tables, and another 50% (in averate
IT applications) are doing "dumb" inserts and queries, where
there is little or no manipulation of the data other
than assigning the primary key. (The numbers are not scientific.
They are about as good as most "effort estimates" that managers
routinely ask developers to give... based on experience).

The other 10% of business objects may have a great deal of
logic under them. These object can have dozens of other classes servicing
that logic, encapsulating complexity and points where change will occur.

If your business layer services thirty business objects, and you have
serious
logic under three of those objects, you have the same percentage that I have seen. If that logic requires the creation of 20 more classes to manage,
that doesn't change my assertion. I suspect that this is NOT the
case with your application, but I assert that this is commonly
the case with the vast majority of applications.

I agree in that this is probably the case with many applications that are
somewhat generic in nature, i.e. shopping carts, AP/AR/GL systems, etc. To
be honest, most of my work is outside of the generic realm of applications,
as I have always worked at an enterprise application development level on
very large, complex and specific applications for either the State of
California and now, the FAA. Needless to say, my experience in the private
sector is limited, and everything you describe must be the way its being
done out there. To my knowledge, and I've tried to find out, my
project/application within the FAA is the only .Net project in the FAA, so
comparisions of whats going on in the public sector are hard to come by.

--

Raymond Lewallen
http://rlewallen.blogspot.com