473,320 Members | 1,841 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Instantiate an object in two ways???

J-T
I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}
B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}
I personally like the second one.Some people say that the second one is not
good because everytime you call doSomthing(..) a new instance is created.I
do agree with it ,but the first approach in an aasp.net application has the
same demrits ,unless you put the object inside application variable or
session variable and persist it.Other wise when you are done working with
the object it is ready for the garbage collector to be collected and when
the second request arrives ,if the object is collected then you need to
create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks
Nov 19 '05 #1
7 1963
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which could
potentially slow down your app if it takes a long time to complete its work,
as well as adding complexity to anything using it, because now it has to
worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation of
this object is not expensive, and it will be garbage collected when the
request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other problems.

"J-T" <J-*@microsft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}
B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}
I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage collector
to be collected and when the second request arrives ,if the object is
collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks

Nov 19 '05 #2
J-T
> The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected. Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it has
no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?
ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

"Marina" <so*****@nospam.com> wrote in message
news:ec**************@TK2MSFTNGP10.phx.gbl... The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation of
this object is not expensive, and it will be garbage collected when the
request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other problems.

"J-T" <J-*@microsft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}
B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}
I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks


Nov 19 '05 #3
1. No, it is not right. When it is a static object, it means it belongs to
class type. And there is only one of that. Once it is instantiated, it stays
around for the lifetime of the application. Meaning until asp.net is shut
down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very very
slow application. This is why I suggested having the static object is not a
way to go - you have to start worrying about multiple threads accessing your
object at the same time.

"J-T" <J-*@microsft.com> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it
has no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?


ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

"Marina" <so*****@nospam.com> wrote in message
news:ec**************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If 2
people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation of
this object is not expensive, and it will be garbage collected when the
request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other problems.

"J-T" <J-*@microsft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}
B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}
I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks



Nov 19 '05 #4
J-T
About the first method,

As you can see ,it is using an static variable ,and I think static variables
are stored in the heap and objects stored on the heap can be accessed by all
threads.My object is a readonly object.what I mean by read only is that none
of the threads are trying to change it ,they only want to use it,so none of
those threads lock the object.Having said all this,do you still think that I
have still thread issue.

Thanks
"Marina" <so*****@nospam.com> wrote in message
news:ur**************@TK2MSFTNGP14.phx.gbl...
1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated, it
stays around for the lifetime of the application. Meaning until asp.net is
shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very very
slow application. This is why I suggested having the static object is not
a way to go - you have to start worrying about multiple threads accessing
your object at the same time.

"J-T" <J-*@microsft.com> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it
has no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?


ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

"Marina" <so*****@nospam.com> wrote in message
news:ec**************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

"J-T" <J-*@microsft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}
B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}
I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks



Nov 19 '05 #5
J-T
If your answer to my previous post is NO,can you guid me to some references
I can read more about that specific behavior?

Thanks a lot for follwoing up this.
"Marina" <so*****@nospam.com> wrote in message
news:ur**************@TK2MSFTNGP14.phx.gbl...
1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated, it
stays around for the lifetime of the application. Meaning until asp.net is
shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very very
slow application. This is why I suggested having the static object is not
a way to go - you have to start worrying about multiple threads accessing
your object at the same time.

"J-T" <J-*@microsft.com> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang around
for a while and if no one else (no other request) uses that one ,then it
has no reference to it and it's ready to be garbage collected.right?

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time?


ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

"Marina" <so*****@nospam.com> wrote in message
news:ec**************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app. It
will not be garbage collected.

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads are
accessing this one instance of the object at the same time? Depending on
what your object does, you may need to synchronize access to it. Which
could potentially slow down your app if it takes a long time to complete
its work, as well as adding complexity to anything using it, because now
it has to worry about making sure it is safe to access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

"J-T" <J-*@microsft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I can instantiate my object in my *ASP.NET* application in two ways:

A)
public sealed class RSSingleton
{

private static ReportingServiceProxy m_RsProxy=null;
static RSSingleton()
{
m_RsProxy = new ReportingServiceProxy();
m_RsProxy.Credentials =
System.Net.CredentialCache.DefaultCredentials;
m_RsProxy.Url =
ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
"/ReportService.asmx";
}
internal static ReportingServiceProxy Instance{get{return m_RsProxy;}}
}
B)
public class RSFactory
{
//Empty constructor
static RSFactory()
{

}
public static ReportingServiceProxy Proxy
{
get
{
ReportingServiceProxy rsProxy = new ReportingServiceProxy();
rsProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
return rsProxy;
}
}
public static string doSomthing(..)
{
Proxy.Render(...)
}
}
I personally like the second one.Some people say that the second one is
not good because everytime you call doSomthing(..) a new instance is
created.I do agree with it ,but the first approach in an aasp.net
application has the same demrits ,unless you put the object inside
application variable or session variable and persist it.Other wise when
you are done working with the object it is ready for the garbage
collector to be collected and when the second request arrives ,if the
object is collected then you need to create another instance.Am I righ?

BTW ReportingServiceProxy is a proxy class of a webservice.

Thanks



Nov 19 '05 #6
If the object will be used for read only purposes, then going the static
route is fine.

"J-T" <J-*@microsft.com> wrote in message
news:OO**************@TK2MSFTNGP10.phx.gbl...
About the first method,

As you can see ,it is using an static variable ,and I think static
variables are stored in the heap and objects stored on the heap can be
accessed by all threads.My object is a readonly object.what I mean by read
only is that none of the threads are trying to change it ,they only want
to use it,so none of those threads lock the object.Having said all this,do
you still think that I have still thread issue.

Thanks
"Marina" <so*****@nospam.com> wrote in message
news:ur**************@TK2MSFTNGP14.phx.gbl...
1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated, it
stays around for the lifetime of the application. Meaning until asp.net
is shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very
very slow application. This is why I suggested having the static object
is not a way to go - you have to start worrying about multiple threads
accessing your object at the same time.

"J-T" <J-*@microsft.com> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app.
It will not be garbage collected.
Why it is not gargage collected? Imagine a request makes this object be
created and when the request is done the object is there ,may hang
around for a while and if no one else (no other request) uses that one
,then it has no reference to it and it's ready to be garbage
collected.right?
However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads
are accessing this one instance of the object at the same time?

ASP.NET application is a multi-threaded one and there is always multiple
threads working with objects it create,There is no way of getting rid of
multiple threads working at the same time ,right?

Thanks for your reply.

"Marina" <so*****@nospam.com> wrote in message
news:ec**************@TK2MSFTNGP10.phx.gbl...
The first way, you will have one instance for the entire asp.net app.
It will not be garbage collected.

However, you are opening yourself up for potential threading issues. If
2 people make a request at the same time, what if both their threads
are accessing this one instance of the object at the same time?
Depending on what your object does, you may need to synchronize access
to it. Which could potentially slow down your app if it takes a long
time to complete its work, as well as adding complexity to anything
using it, because now it has to worry about making sure it is safe to
access this object.

For asp.net, hands down I would go with way #2. Odds are, the creation
of this object is not expensive, and it will be garbage collected when
the request is finished. You aren't really going to see a noticeable
performance difference, and you will avoid a whole lot of other
problems.

"J-T" <J-*@microsft.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
>I can instantiate my object in my *ASP.NET* application in two ways:
>
> A)
> public sealed class RSSingleton
> {
>
> private static ReportingServiceProxy m_RsProxy=null;
> static RSSingleton()
> {
> m_RsProxy = new ReportingServiceProxy();
> m_RsProxy.Credentials =
> System.Net.CredentialCache.DefaultCredentials;
> m_RsProxy.Url =
> ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
> "/ReportService.asmx";
> }
> internal static ReportingServiceProxy Instance{get{return
> m_RsProxy;}}
> }
>
>
> B)
> public class RSFactory
> {
> //Empty constructor
> static RSFactory()
> {
>
> }
> public static ReportingServiceProxy Proxy
> {
> get
> {
> ReportingServiceProxy rsProxy = new ReportingServiceProxy();
> rsProxy.Credentials =
> System.Net.CredentialCache.DefaultCredentials;
> return rsProxy;
> }
> }
> public static string doSomthing(..)
> {
> Proxy.Render(...)
> }
> }
>
>
> I personally like the second one.Some people say that the second one
> is not good because everytime you call doSomthing(..) a new instance
> is created.I do agree with it ,but the first approach in an aasp.net
> application has the same demrits ,unless you put the object inside
> application variable or session variable and persist it.Other wise
> when you are done working with the object it is ready for the garbage
> collector to be collected and when the second request arrives ,if the
> object is collected then you need to create another instance.Am I
> righ?
>
> BTW ReportingServiceProxy is a proxy class of a webservice.
>
> Thanks
>



Nov 19 '05 #7
J-T
Thanks a lot for your nice help
"Marina" <so*****@nospam.com> wrote in message
news:eZ**************@TK2MSFTNGP10.phx.gbl...
If the object will be used for read only purposes, then going the static
route is fine.

"J-T" <J-*@microsft.com> wrote in message
news:OO**************@TK2MSFTNGP10.phx.gbl...
About the first method,

As you can see ,it is using an static variable ,and I think static
variables are stored in the heap and objects stored on the heap can be
accessed by all threads.My object is a readonly object.what I mean by
read only is that none of the threads are trying to change it ,they only
want to use it,so none of those threads lock the object.Having said all
this,do you still think that I have still thread issue.

Thanks
"Marina" <so*****@nospam.com> wrote in message
news:ur**************@TK2MSFTNGP14.phx.gbl...
1. No, it is not right. When it is a static object, it means it belongs
to class type. And there is only one of that. Once it is instantiated,
it stays around for the lifetime of the application. Meaning until
asp.net is shut down or recycled.

2. ASP.NET is multithreaded - and if it wasn't, you would have a very
very slow application. This is why I suggested having the static object
is not a way to go - you have to start worrying about multiple threads
accessing your object at the same time.

"J-T" <J-*@microsft.com> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...
> The first way, you will have one instance for the entire asp.net app.
> It will not be garbage collected.
Why it is not gargage collected? Imagine a request makes this object
be created and when the request is done the object is there ,may hang
around for a while and if no one else (no other request) uses that one
,then it has no reference to it and it's ready to be garbage
collected.right?
> However, you are opening yourself up for potential threading issues.
> If 2 people make a request at the same time, what if both their
> threads are accessing this one instance of the object at the same
> time?

ASP.NET application is a multi-threaded one and there is always
multiple threads working with objects it create,There is no way of
getting rid of multiple threads working at the same time ,right?

Thanks for your reply.

"Marina" <so*****@nospam.com> wrote in message
news:ec**************@TK2MSFTNGP10.phx.gbl...
> The first way, you will have one instance for the entire asp.net app.
> It will not be garbage collected.
>
> However, you are opening yourself up for potential threading issues.
> If 2 people make a request at the same time, what if both their
> threads are accessing this one instance of the object at the same
> time? Depending on what your object does, you may need to synchronize
> access to it. Which could potentially slow down your app if it takes a
> long time to complete its work, as well as adding complexity to
> anything using it, because now it has to worry about making sure it is
> safe to access this object.
>
> For asp.net, hands down I would go with way #2. Odds are, the creation
> of this object is not expensive, and it will be garbage collected when
> the request is finished. You aren't really going to see a noticeable
> performance difference, and you will avoid a whole lot of other
> problems.
>
> "J-T" <J-*@microsft.com> wrote in message
> news:%2****************@TK2MSFTNGP10.phx.gbl...
>>I can instantiate my object in my *ASP.NET* application in two ways:
>>
>> A)
>> public sealed class RSSingleton
>> {
>>
>> private static ReportingServiceProxy m_RsProxy=null;
>> static RSSingleton()
>> {
>> m_RsProxy = new ReportingServiceProxy();
>> m_RsProxy.Credentials =
>> System.Net.CredentialCache.DefaultCredentials;
>> m_RsProxy.Url =
>> ConfigurationSettings.AppSettings[Constants.CONFIG_RS_URL] +
>> "/ReportService.asmx";
>> }
>> internal static ReportingServiceProxy Instance{get{return
>> m_RsProxy;}}
>> }
>>
>>
>> B)
>> public class RSFactory
>> {
>> //Empty constructor
>> static RSFactory()
>> {
>>
>> }
>> public static ReportingServiceProxy Proxy
>> {
>> get
>> {
>> ReportingServiceProxy rsProxy = new ReportingServiceProxy();
>> rsProxy.Credentials =
>> System.Net.CredentialCache.DefaultCredentials;
>> return rsProxy;
>> }
>> }
>> public static string doSomthing(..)
>> {
>> Proxy.Render(...)
>> }
>> }
>>
>>
>> I personally like the second one.Some people say that the second one
>> is not good because everytime you call doSomthing(..) a new instance
>> is created.I do agree with it ,but the first approach in an aasp.net
>> application has the same demrits ,unless you put the object inside
>> application variable or session variable and persist it.Other wise
>> when you are done working with the object it is ready for the garbage
>> collector to be collected and when the second request arrives ,if the
>> object is collected then you need to create another instance.Am I
>> righ?
>>
>> BTW ReportingServiceProxy is a proxy class of a webservice.
>>
>> Thanks
>>
>
>



Nov 19 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Colin Mc Mahon | last post by:
Hi all, I currently use a class to interface with my databases, allowing me to insert, update, delete and retrieve records from the database as methods of the class. I have now created a...
8
by: Carel Lotz | last post by:
H We have ported our VB 6 application into VB .NET but are still integrating with a few COM + applications written in VB6 running on our application server (Win 2000 Server). We have the proxies...
5
by: thechaosengine | last post by:
Hi everyone, I've been looking at the various ways to create a data access layer recently. There was one thing in particular that occured to me and I was hoping to garner some experienced...
5
by: Glenn Serpas | last post by:
I have Class A and Class B .. Class B has a private member that is a pointer to a Class A object. private: B *mypointer ; I instantiate the A object A* myobject new = A();
16
by: gabon | last post by:
Due a big project I would like to create different javascript classes and assign them to divs. But how? :) I know the usage of prototype but given that this could be possible: function...
9
by: the_grove_man | last post by:
I guess my question can go in two directions. I create applications that run multiple queries against a database. Generally speaking in the past I have used a Data Control (calling it dat1)...
13
by: Brian | last post by:
I have many similar classes in a project, one for each type of report my app can create. I want to instantiate them based on a value passed in by a scheduler module. Right now I have Sub...
4
by: Tomas | last post by:
A newbie question: How can I instantiate objects dynamically in VB.NET. E.g. I have the object 'Player' and I would like to instantiate it with the several instances (James, Gunner, etc.), without...
5
by: RyanN | last post by:
Hello, I'm trying to teach myself OOP to do a data project involving hierarchical data structures. I've come up with an analogy for testing involving objects for continents, countries, and...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.