OO + 3-Tier design Q

[news.microsoft.com]

I'm trying to develop a ASP.NET app with OO + 3-tier design, here is a
scenario:
if there is a People class which is defined as below,
class People
{
string ID;
string FirstName;
string LastName;
string Address;
string Tel;
}

Then there are 2 webform page, one will display only ID,FirstName and
LastName properties of
the People object but another one will display all the properties.

Q1: both the two webform pages can use same People object or I should create
and declare two
classes as below for each webform page? which one is better on maintenance
and performance?

class BasePeople
{
string ID;
string FirstName;
string LastName;
}

class People: BasePeople
{
string Address;
string Tel;
}

Q2: The Data layer should read all the columns from db and the Biz Logic
layer selects required fields to
fill in the People object?
or the data layer only fetches required columns from db in the beginning?

Thanks in advance.

 

[Scott Roberts]

I'm trying to develop a ASP.NET app with OO + 3-tier design, here is a
scenario:
if there is a People class which is defined as below,
class People
{
string ID;
string FirstName;
string LastName;
string Address;
string Tel;
}

Then there are 2 webform page, one will display only ID,FirstName and
LastName properties of
the People object but another one will display all the properties.

Q1: both the two webform pages can use same People object or I should
create and declare two
classes as below for each webform page? which one is better on maintenance
and performance?

Are you asking if you should cache the object across postbacks? In general,
I'd say no. Caching for an individual user, maybe. Caching application-wide,
generally no. I guess if the data is relatively static (e.g. a list of US
States) you could, but not a People class. At the very least, provide a way
to "refresh" the cached object, especially during debugging.

class BasePeople
{
string ID;
string FirstName;
string LastName;
}

class People: BasePeople
{
string Address;
string Tel;
}

Q2: The Data layer should read all the columns from db and the Biz Logic
layer selects required fields to
fill in the People object?
or the data layer only fetches required columns from db in the beginning?

We have "default load" fields that are configured at design-time. They can
be overridden at run-time if necessary. The DAL generates dynamic SQL that
only returns the fields that will be loaded.

 

[Arne Vajhøj]

I'm trying to develop a ASP.NET app with OO + 3-tier design, here is a
scenario:
if there is a People class which is defined as below,
class People
{
string ID;
string FirstName;
string LastName;
string Address;
string Tel;
}

Then there are 2 webform page, one will display only ID,FirstName and
LastName properties of
the People object but another one will display all the properties.

Q1: both the two webform pages can use same People object or I should create
and declare two
classes as below for each webform page? which one is better on maintenance
and performance?

class BasePeople
{
string ID;
string FirstName;
string LastName;
}

class People: BasePeople
{
string Address;
string Tel;
}

Class structure is about modeling.

Does the business distinguish between people with just base info and
people with address and telephone number ?

If no then I would say one class.

Q2: The Data layer should read all the columns from db and the Biz Logic
layer selects required fields to
fill in the People object?
or the data layer only fetches required columns from db in the beginning?

If data is in one table and there are no LOB's, then get all the data
at once.

Arne

 

[Redhairs]

Class structure is about modeling.

Does the business distinguish between people with just base info and
people with address and telephone number ?

If no then I would say one class.

No, just display whole or partial information in presentation layer.

If data is in one table and there are no LOB's, then get all the data
at once.

Arne

You mean loading all the data at once in Data layer, if I only need ID/Names
properties in certain page, then I should fill in all data into the people
pbject
or just fill in the ID/name properties but keep other properties as null in
Biz layer?

 

[Redhairs]

We have "default load" fields that are configured at design-time. They can
be overridden at run-time if necessary. The DAL generates dynamic SQL that
only returns the fields that will be loaded.

In this case, if the DAL only return required fields, how about the other
properties
of the people object? just keep them as null? Does a null property occupy
same memory/resource
as a non-null property within a class?

Btw, the logic of dynamic SQL generation should be implemented in DAL or BLL
tier?

 

[Scott Roberts]

In this case, if the DAL only return required fields, how about the other
properties
of the people object? just keep them as null?

That's one option. It really depends on how complex you want to get.

Does a null property occupy same memory/resource
as a non-null property within a class?

I'm not 100% certain on that that. For strings, the answer is definitely
"no". For other nullable-types, I'm not sure, but probably.

Btw, the logic of dynamic SQL generation should be implemented in DAL or
BLL tier?

SQL generation is certainly not "business logic".

 

[Redhairs]

That's one option. It really depends on how complex you want to get.


I'm not 100% certain on that that. For strings, the answer is definitely
"no". For other nullable-types, I'm not sure, but probably.


SQL generation is certainly not "business logic".

Thanks!
Will the dynamic SQL generation raise another issue as below?
Since I plan to cache the data retrieved by DAL for BLL, the dynamic query
result
will create many cache objects and they may have some same fields.

Ex: if a product class has many prices depends the user's membership, how
should I design
the DAL and BLL?

The DAL reads all the price columns from db and fill in the object below at
once? then cache it ?
class DALproduct
{
string ID;
int GoldPrice;
int SilverPrice;
int RetailPrice;
int DiscountPrice;
}

The BLL read cache DAL object(DALproduct class) but only fill appropriate
price into BLL object below
based on the membership logic?

class BLLLproduct
{
string ID;
int ThePrice;
}

 

[Redhairs]

I'm not 100% certain on that that. For strings, the answer is definitely
"no". For other nullable-types, I'm not sure, but probably.

If a null property also occupies some resorce or bandwidth (from db to DAL
and from DAL to BLL) , should I use different class structure/schema with
the
dynamic SQL to fetch and fill the required clumns only?

 

[Scott Roberts]

If a null property also occupies some resorce or bandwidth (from db to DAL
and from DAL to BLL) , should I use different class structure/schema with
the
dynamic SQL to fetch and fill the required clumns only?

I'd say no.

In our case, while we do use dynamically generated SQL, there are "default"
fields to be loaded (designated at design-time) so it really ends up being
the same SQL 99% of the time. We primarily only exclude LOBs from the
"default" SQL that gets generated (like someone else already mentioned).

 

[Arne Vajhøj]

You mean loading all the data at once in Data layer, if I only need ID/Names
properties in certain page, then I should fill in all data into the people
pbject
or just fill in the ID/name properties but keep other properties as null in
Biz layer?

I would fill in all the data.

It is the cleanest design and those 50-100 bytes does not have any
impact on performance (in the context described).

Arne

 

[Arne Vajhøj]

If a null property also occupies some resorce or bandwidth (from db to DAL
and from DAL to BLL) , should I use different class structure/schema with
the
dynamic SQL to fetch and fill the required clumns only?

A null will take up 4 or 8 bytes I assume (on 32 bit and 64 bit
respectively).

Very important if you are coding in C for an embedded device with 4 KB
memory in total.

But irrelevant if we are talking about data to display on a screen
on a modern PC.

Even if you had 10 of these fields on 64 bit windows and had
10000 users showing data simultaneously, then it would only
be 800 KB of memory. Not even noticeable.

You should focus on what has a real impact.

Arne

 

[Redhairs]

I would fill in all the data.

It is the cleanest design and those 50-100 bytes does not have any
impact on performance (in the context described).

Arne

Ex: if a product class has many prices depends the user's membership, how
should I design the DAL and BLL?

The DAL reads all the price columns from db and fill in the object below at
once? then cache it ?
class DALproduct
{
string ID;
int GoldPrice;
int SilverPrice;
int RetailPrice;
int DiscountPrice;
}

The BLL read cache DAL object(DALproduct class) but only fill appropriate
price into BLL object below based on the membership logic?

class BLLproduct
{
string ID;
int ThePrice;
}

Or other better option?

 

[Mr. Arnold]

I'm trying to develop a ASP.NET app with OO + 3-tier design, here is a
scenario:
if there is a People class which is defined as below,
class People
{
string ID;
string FirstName;
string LastName;
string Address;
string Tel;
}

Then there are 2 webform page, one will display only ID,FirstName and
LastName properties of
the People object but another one will display all the properties.

Q1: both the two webform pages can use same People object or I should
create and declare two
classes as below for each webform page? which one is better on maintenance
and performance?

What performance issue both forms should use the same business object with
one form using the properties in needs and the other form using the
properties it needs aout of the object.

Why does it need to be anymore complicated than that?

class BasePeople
{
string ID;
string FirstName;
string LastName;
}

class People: BasePeople
{
string Address;
string Tel;
}


Q2: The Data layer should read all the columns from db and the Biz Logic
layer selects required fields to
fill in the People object?
or the data layer only fetches required columns from db in the beginning?

The Business object instantiates the DAL object. The DAL object fills its
like properties as those defined in the Bossiness object from the database.
The DAL object returns itself to the Business object, the Bus object
populates itself from like properties from the DAL object. The UI has access
to the Bus object properties.

Better yet, the UI has no awareness of the Bus object -- loosely coupled.
The UI goes through the Presentation layer to access the Business layer
through interfaces, and the Bus layer accesses the DAL.

MODEL-VIEW-PRESENTER
http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns'

view part 1-5

 

[sloan]

You can see my example of this at
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

code is downloadable.

...

If you had something like

class Person

class Manager : Person

class Employee : Manager

then maybe you do seperate mappers.



But I would not do a seperate mapper to save space on a few extra fields (as
your example portrays).
Just populate it all, and only use what you want. Its its a subset, then so
be it.


............