N-Tier Application - Question about Static Methods

[dn]

I'm starting an n-tier application with an ASP.NET 2.0 presentation layer, a
business layer, a data access layer, and a SQL Server 2005 database, and I
have a question.

In the business and data access layers, should I use static methods? Or,
should I code the classes so that they have to be instantiated? I've seen
examples of both, and I'm not sure which is the "preferred" or "best" way.

Thanks.

 

[Michael S]

I'm starting an n-tier application with an ASP.NET 2.0 presentation layer,
a
business layer, a data access layer, and a SQL Server 2005 database, and I
have a question.

In the business and data access layers, should I use static methods? Or,
should I code the classes so that they have to be instantiated? I've seen
examples of both, and I'm not sure which is the "preferred" or "best" way.

Thanks.

We're currently building a SOA system right now and we use a combined model
in the Business Facade.


class Customer
{
public int Id;
public string Name;
public static Customer GetCustomer(int id)
{
SomeData data = /* fetch data some how. */

Customer c = new Customer();
c.id = id;
c.Name = data.Name;
return c;
}
}

First time we tried this approach and we really like it. The Customer is its
own Factory.
But most often our classes is a typed DataSet and then you get your class by
clicking away in vs2005.

- Michael S

 

[Kevin Spencer]

Static methods are useful when you dont' need access to any member in the
class in which the methods are created. The reason for this is simply saving
memory. An instance method is a method which is included in an instance of a
class. When the class is instantiated, a copy of the class is placed on the
stack. This means that, for every copy of the class, a copy of the method is
created. A static method remains in the heap; there is only one instance of
it. So, if the method does not need to access any instance members of the
class, it can be a static method, and save memory. It *can* access other
static members of the class, or any other static members of any class that
is accessible to it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Michael S]

Static methods are useful when you dont' need access to any member in the
class in which the methods are created. The reason for this is simply
saving memory. An instance method is a method which is included in an
instance of a class. When the class is instantiated, a copy of the class
is placed on the stack. This means that, for every copy of the class, a
copy of the method is created. A static method remains in the heap; there
is only one instance of it. So, if the method does not need to access any
instance members of the class, it can be a static method, and save memory.
It *can* access other static members of the class, or any other static
members of any class that is accessible to it.

Boy, do you have some learning to do.. You are wrong on all accounts.

- Michael S

 

[theiwaz]

I'm starting an n-tier application with an ASP.NET 2.0 presentation layer, a
business layer, a data access layer, and a SQL Server 2005 database, and I
have a question.

In the business and data access layers, should I use static methods? Or,
should I code the classes so that they have to be instantiated? I've seen
examples of both, and I'm not sure which is the "preferred" or "best" way.

Thanks.

The question of using static methods does not depend on the layer.
1. Static method usually provide functionallity which are not instance
related.
They can be used for creating instances (factories), converting
purposes (System.Convert), or other useful things with instances
(String.Concat).

2. The strategy to use this for an application design (let's say
factories should create biz objects) works fine with static methods.
Why ? Because the design of the factory pattern makes it useful the
have functionality which has no direct relation to an instance of that
particular factory.

I hope this helps
cheers, Marcus

 

[Kevin Spencer]

Good argument Michael.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Franky]

static methods are made for use in things like int.Parse(string s)
(stuctures and very simple datatypes) but not for use in business layers!!!

it may now be easy to use them but in time you will pay for that when
your system seems to be very hard to maintain.

read the following two documents!
http://msdn.microsoft.com/practices....aspx?pull=/library/en-us/dnbda/html/daag.asp
and
http://msdn.microsoft.com/practices...spx?pull=/library/en-us/dnbda/html/boagag.asp

these will give you excellent information on how to build business
layers and data layers

greetz Dries

 

[Guest]

Static methods are useful when you dont' need access to any member in the
class in which the methods are created. The reason for this is simply saving
memory. An instance method is a method which is included in an instance of a
class. When the class is instantiated, a copy of the class is placed on the
stack. This means that, for every copy of the class, a copy of the method is
created. A static method remains in the heap; there is only one instance of
it. So, if the method does not need to access any instance members of the
class, it can be a static method, and save memory. It *can* access other
static members of the class, or any other static members of any class that
is accessible to it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

All Objects of a Class Share Just One Copy of Each Instance Method

Because each instance method is executed in relation to a specific object,
it seems that there exists one particular instance method copy in the memory
per object. However, this is not the case, because it would consume far too
much memory. Instead, all objects of the same class share just one copy of
each instance method.

The Rocket class shown next illustrates this point. Two Rocket objects are
created and their references assigned to rocketA and rocketB, respectively
(lines 30 and 31). Even though there is only one copy of the Launch method,
rocketA.Launch() (line 40) still executes Launch in relation to rocketA, and
rocketB.Launch() (line 41) executes Launch in relation to rocketB.

01: class Rocket
02: {
03: private double speed;
...
10: public void Launch()
11: {
...
15: speed = 3000.9;
...
20: }
...
25: }

30: Rocket rocketA = new Rocket();
31: Rocket rocketB = new Rocket();

40: rocketA.Launch();
41: rocketB.Launch();

How can C# make this possible? The compiler secretly passes the reference of
the object for which the method is called along as an argument to the
instance method. If you could look down into the engine room of the compiler,
it might look like the following lines:

Rocket.Launch (rocketA);
Rocket.Launch (rocketB);

The compiler then (also secretly) attaches the object reference to any code
inside the method that is specific to the object. For example, during the
Rocket.Launch(rocketA) call, the following line

speed = 3000.9

becomes equivalent to

rocketA.speed = 3000.9

 

[Kevin Spencer]

Thanks Jesika. I stand corrected. Good stuff.

--

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[theiwaz]

static methods are made for use in things like int.Parse(string s)
(stuctures and very simple datatypes) but not for use in business layers!!!

it may now be easy to use them but in time you will pay for that when
your system seems to be very hard to maintain.

read the following two documents!
http://msdn.microsoft.com/practices....aspx?pull=/library/en-us/dnbda/html/daag.asp
and
http://msdn.microsoft.com/practices...spx?pull=/library/en-us/dnbda/html/boagag.asp

these will give you excellent information on how to build business
layers and data layers

greetz Dries

Hey Dries,

I do not want to be unkind but did you read the documents to wich you
refer ?

The only paragraph I found where they say avoid using static methods is
in conjunction to COM Interop. Actually the give many examples where
they DO USE static methods.

As I mentioned: Static methods are just a feature of a programming
language. Which you can use within you biz layers or anywhere else in
your code. But in some cases an implementation of a pattern can be done
very smart by using them.

Cheers,

Marcus

 

[Michael S]

I meant all that Jesika wrote, but my reply was more terse... =)

- Michael S

 

[Franky]

Franky schrieb:




Hey Dries,

I do not want to be unkind but did you read the documents to wich you
refer ?

The only paragraph I found where they say avoid using static methods is
in conjunction to COM Interop. Actually the give many examples where
they DO USE static methods.

As I mentioned: Static methods are just a feature of a programming
language. Which you can use within you biz layers or anywhere else in
your code. But in some cases an implementation of a pattern can be done
very smart by using them.

Cheers,

Marcus

Marcus, I fully agree with you that static methods can be vert useful,
but I strongly doubt if it is a good solution to use them in a multitier
application.

The example mentioned:

public class Customer
{
public Customer()
{
}
public static Customer GetCustomer(int id)
{
}
}

Where will you put your code to access your database? I hope not in the
static method.

What I do, and I think that's what is described in those documents, is
creating two assemblies: one assembly contains the class Customer with
only properties (and a few methods).

Functionality like GetCustomer(int id) is put in the second assembly.
This second assembly contains all code to access the database and return
Business Objects from the first assembly.

You can compare this with the DataSet and the SqlDataAdapter e.g.: there
is no static method in the DataSet class the get a DataSet filled with
data. You should first create a DataSet and then use a (Sql)DataAdapter
to fill it with data. And this is a real multitier app!!

You will never have to change you DataSet when you want to use another
DataAdapter (Sql, OleDb, Oracle...).

That is why I think static methods are nog the best practice for
multitier apps.

grtz,

 

[Kevin Spencer]

More terse, and not helpful.

I do not wish to disseminate false information. If I am wrong about
something, I want to know what is correct. Having someone tell me I'm wrong
without explanation is not useful to anyone reading the thread. Anyone can
say that something is wrong, and they may be wrong in saying so. This has
happened to me before, many times. The only proof of the veracity of such a
statement is evidence. The evidence given is useful to everyone reading the
thread. In fact, any statement made in a newsgroup without evidence is not
necessarily useful, as there are many people who make incorrect statements,
either unwittingly, or willfully.

We are here, after all, to help each other out, right?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Michael S]

The example mentioned:

public class Customer
{
public Customer()
{
}
public static Customer GetCustomer(int id)
{
}
}

Where will you put your code to access your database? I hope not in the
static method.

Why not? Depends on requirements.

I don't question your arhictecture of using two assemblies. By using two
layers you can scale over two tiers if the need should arise.

In the current project I'm working on now, this is not an issue. We simply
won't need to scale. Why should the customer pay for and extra layer we
don't need?

Both designs may be great, depending on the requirements.

- Michael S

 

[Michael S]

You are right, and I was an arrogant bastard.

Now - I stand corrected.

Happy Coding
- Michael S

 

[theiwaz]

Franky,

two options:

Either the Customer object in your example uses the data access layer
to
create cutomer objects. In this case the customer factory resides in
the biz layer.

Or you use leightweight objects which does not ahve any (load, save,
etc) methods, and are created by related factories of the data access
layer.

Both ways are VERY common and often used. In the .NET world AND the
JAVA world.

Cheers,
Marcus