DAL is physical mapping and BLL logical?

[MattM]

Looking at a tutorial for Asp.Net 2.0 using Northwind, the DAL was built by
dragging the tables on to an XSN to create a dataTable object for each table
in the database. The BLL was then mapped for each entity but since the data
was simple it mapped to a physical table (ex. customer). But what do you do
if your tables don't match up the physical and logical?

For example, you could have a table for people, a table for job codes, and a
table for payroll schedules. These tables are each separte but they are
linked logically. You could create an "employee" object that would contain
information from all 3 physical tables if you used a traditional OOP
approach.

What I'm not sure is where would you implement a logical object. Does it
belong at the DAL level? That would mean that perhaps the physical mapping to
each table is incorrect. Or does it belong in the BLL? That would mean your
BLL would be similar to an object but I think it would also confuse auto data
binding to controls (I think). Or maybe there's another option I'm missing.

I think a logical class or object like "employee" is what makes most sense.
But I'm not sure where such a definition belongs and whether or not some of
the object data source binding in 2.0 will work with objects that do not map
directly to physical tables.

[sloan]

http://sholliday.spaces.live.com/blog/

See May/2006 and June/2006 entries.

I think you'll see a better option if you don't have a direct "database
table to business entity" situation.

The "serialize" method ... gives you the control over how you get the data
from the database to your business entity.

"MattM" <Ma***@discussions.microsoft.comwrote in message
news:04**********************************@microsof t.com...

Looking at a tutorial for Asp.Net 2.0 using Northwind, the DAL was built

by

dragging the tables on to an XSN to create a dataTable object for each

table

in the database. The BLL was then mapped for each entity but since the

data

was simple it mapped to a physical table (ex. customer). But what do you

do

if your tables don't match up the physical and logical?

For example, you could have a table for people, a table for job codes, and

a

table for payroll schedules. These tables are each separte but they are
linked logically. You could create an "employee" object that would contain
information from all 3 physical tables if you used a traditional OOP
approach.

What I'm not sure is where would you implement a logical object. Does it
belong at the DAL level? That would mean that perhaps the physical mapping

to

each table is incorrect. Or does it belong in the BLL? That would mean

your

BLL would be similar to an object but I think it would also confuse auto

data

binding to controls (I think). Or maybe there's another option I'm

missing.

>
I think a logical class or object like "employee" is what makes most

sense.

But I'm not sure where such a definition belongs and whether or not some

of

the object data source binding in 2.0 will work with objects that do not

map

directly to physical tables.