This really shouldn't have much code in it anyway

private void DataGrid1_UpdateCommand(object source,
System.Web.UI.WebControls.DataGridCommandEventArgs e)
{
/* don't put logic here. only lines to call your logic elsewhere */
}
You should not business logic in your controls. You should
not put business logic (no matter how small) in your event
handling sections or even form methods.
You'll be much better off enhancing your application if
your business rules are in classes that are not tied directly
to your UI or business layers outside of the parameters
passed in.
Robbe Morris - 2004/2005 Microsoft MVP C#
Earn money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp
<apandapion@dotnet.itags.org.gmail.com> wrote in message
news:1124130872.659013.20810@dotnet.itags.org.g47g2000cwa.googlegroups.com...
> I'm working with csharp and .net for the first time, and I've had a
> fair amount of luck. I started with the MSDN "Walkthrough : Creating a
> Distributed Application" tutorial and expanded from there, adding state
> management and other assorted things.
> So I have a lot of code that looks like this:
> private void DataGrid1_UpdateCommand(object source,
> System.Web.UI.WebControls.DataGridCommandEventArgs e)
> {
> /* snip lots of code that I've written */
> }
> It wraps a dataset obtained through a pretty standard two function
> GetTable/UpdateTable web service.
> I want to reuse this code, and not in the braindead
> cut/paste/alter/suffer manner. Under the .net architecture, what's the
> best way to go about it? Write my own class that inherits from
> DataGrid? I tried that, and it encapsulates the code nicely, but it
> also causes lots of errors from the aspx file that I'm not sure how to
> handle. Do I have to write a web custom control? Do I lose access to
> the designer in doing so?
>Morris, that's pretty much what I said. We agree on the theory. I'm
looking for a good way to reencapsulate the code, as in, "what language
construct should I use?" Inherit from DataGrid? Write a helper
object? Write my own macro preprocessor?
It's a little hard to encapsulate anything coming off of the XML soap
interface, as the objects are not objects but just a pair of get/put
function calls. And the ASPX side of my module seems to react very
strangely to me inheriting from DataGrid.
I had no trouble working out how to plug COM objects together, back in
the day, as life was just a matter of locating, implementing and
invoking interfaces. Dotnet is a lot easier to work with, so far, but
it's not abundantly clear how I'm supposed to both encapsulate my own
code and interact with the twisty maze of microsoft objects that I have
to talk to on all sides. I would like to think that dotnet is good for
more than toys, but I haven't seen real evidence of that so far.
Can you recommend some books, or technical articles, that demonstrate
the right way to do things? I don't want clouds with lines between
them... I want code. It would be nice to do things "the right way",
from the beginning, but right now I'm just a ser after the way.

Thread safe singleton to access the cache?

I'm trying to nail down some issues with the cache in my application.
Currently, I have an object that stands between my business logic and
database logic called CacheLogic (cute, no?). Global.asax.cs creates it in
Application_Start, initializes it and places it in the cache. During
initialization, CacheLogic retrieves data from the DB logic layer and caches
it with removal callbacks set. Whenever an object in the business logic
layer needs data, it grabs the CacheLogic object from the cache (that's a
violation of the layer right there, I know), and requests the needed data
from it. CacheLogic retrieves the data from the cache and returns it. If the
data is not in the cache, it retrieves the data from the database logic
layer, caches it (with removal callbacks), and then returns the data.

I'm concerned about what happens when two clients are requesting the same
data at the same time when that data is not in the cache. Right now, as I
understand it, CacheLogic will hit the database and cache the data twice.
I'm not sure what side effects that might have, so I'm trying to figure out
ways to avoid this situation completely without killing performance (i.e.,
lock(HttpContext.Current.Cache)).

To make CacheLogic more thread safe, I can lock on a sync object in the
class when I write to the cache or use Mutex. But what use is that unless I
also lock when I read from the cache? And isn't that just as bad as locking
the cache object itself?

The other issue I have is that CacheLogic stores objects in the cache with
removal callbacks pointing to methods in the CacheLogic object. If I create
CacheLogic objects willy-nilly, I could end up with multiple objects in
memory, referenced only by the callback in some cache object. Sounds too
close to a memory leak for me. Currently, by storing a single CacheLogic
object in the cache itself, I have one single object that handles caching and
callbacks for all client connections. I'm not happy that in order to get the
CacheLogic object, other objects have to violate the layers and access the
cache directly.

Do I even need to worry about keeping a single CacheLogic object? Is
converting CacheLogic into a singleton (is there an ISingleton interface?) a
good solution to this problem? And, if I do, once I use the CacheLogic
singleton in Application_Start (assuming I code it properly), will it be
truly available to all clients who call CacheLogic.GetInstance()?you are correct need to lock the cache on read and writes. how well you
design the locking will control how mush a bottleneck it will. if the cache
is readonly, (and the cache objects are thread safe), then you only need to
synchronize access to the cache, not the objects themselves.

not sure what your removal callbacks are used for. typically caches allow
removal of any object at anytime, to allow cache pruning.

switching to a Singleton is just a design pattern (static method to access
object), it does not change your locking issues, you still need to handle
these.

-- bruce (sqlwork.com)

"William Sullivan" <WilliamSullivan@.discussions.microsoft.com> wrote in
message news:D0527EBA-8DAD-464E-92AA-558F32F4AE44@.microsoft.com...
> I'm trying to nail down some issues with the cache in my application.
> Currently, I have an object that stands between my business logic and
> database logic called CacheLogic (cute, no?). Global.asax.cs creates it
> in
> Application_Start, initializes it and places it in the cache. During
> initialization, CacheLogic retrieves data from the DB logic layer and
> caches
> it with removal callbacks set. Whenever an object in the business logic
> layer needs data, it grabs the CacheLogic object from the cache (that's a
> violation of the layer right there, I know), and requests the needed data
> from it. CacheLogic retrieves the data from the cache and returns it. If
> the
> data is not in the cache, it retrieves the data from the database logic
> layer, caches it (with removal callbacks), and then returns the data.
> I'm concerned about what happens when two clients are requesting the same
> data at the same time when that data is not in the cache. Right now, as I
> understand it, CacheLogic will hit the database and cache the data twice.
> I'm not sure what side effects that might have, so I'm trying to figure
> out
> ways to avoid this situation completely without killing performance (i.e.,
> lock(HttpContext.Current.Cache)).
> To make CacheLogic more thread safe, I can lock on a sync object in the
> class when I write to the cache or use Mutex. But what use is that unless
> I
> also lock when I read from the cache? And isn't that just as bad as
> locking
> the cache object itself?
> The other issue I have is that CacheLogic stores objects in the cache with
> removal callbacks pointing to methods in the CacheLogic object. If I
> create
> CacheLogic objects willy-nilly, I could end up with multiple objects in
> memory, referenced only by the callback in some cache object. Sounds too
> close to a memory leak for me. Currently, by storing a single CacheLogic
> object in the cache itself, I have one single object that handles caching
> and
> callbacks for all client connections. I'm not happy that in order to get
> the
> CacheLogic object, other objects have to violate the layers and access the
> cache directly.
> Do I even need to worry about keeping a single CacheLogic object? Is
> converting CacheLogic into a singleton (is there an ISingleton interface?)
> a
> good solution to this problem? And, if I do, once I use the CacheLogic
> singleton in Application_Start (assuming I code it properly), will it be
> truly available to all clients who call CacheLogic.GetInstance()?

Thread safe singleton to access the cache?

I'm trying to nail down some issues with the cache in my application.
Currently, I have an object that stands between my business logic and
database logic called CacheLogic (cute, no?). Global.asax.cs creates it in
Application_Start, initializes it and places it in the cache. During
initialization, CacheLogic retrieves data from the DB logic layer and caches
it with removal callbacks set. Whenever an object in the business logic
layer needs data, it grabs the CacheLogic object from the cache (that's a
violation of the layer right there, I know), and requests the needed data
from it. CacheLogic retrieves the data from the cache and returns it. If th
e
data is not in the cache, it retrieves the data from the database logic
layer, caches it (with removal callbacks), and then returns the data.
I'm concerned about what happens when two clients are requesting the same
data at the same time when that data is not in the cache. Right now, as I
understand it, CacheLogic will hit the database and cache the data twice.
I'm not sure what side effects that might have, so I'm trying to figure out
ways to avoid this situation completely without killing performance (i.e.,
lock(HttpContext.Current.Cache)).
To make CacheLogic more thread safe, I can lock on a sync object in the
class when I write to the cache or use Mutex. But what use is that unless I
also lock when I read from the cache? And isn't that just as bad as lockin
g
the cache object itself?
The other issue I have is that CacheLogic stores objects in the cache with
removal callbacks pointing to methods in the CacheLogic object. If I create
CacheLogic objects willy-nilly, I could end up with multiple objects in
memory, referenced only by the callback in some cache object. Sounds too
close to a memory leak for me. Currently, by storing a single CacheLogic
object in the cache itself, I have one single object that handles caching an
d
callbacks for all client connections. I'm not happy that in order to get th
e
CacheLogic object, other objects have to violate the layers and access the
cache directly.
Do I even need to worry about keeping a single CacheLogic object? Is
converting CacheLogic into a singleton (is there an ISingleton interface?) a
good solution to this problem? And, if I do, once I use the CacheLogic
singleton in Application_Start (assuming I code it properly), will it be
truly available to all clients who call CacheLogic.GetInstance()?you are correct need to lock the cache on read and writes. how well you
design the locking will control how mush a bottleneck it will. if the cache
is readonly, (and the cache objects are thread safe), then you only need to
synchronize access to the cache, not the objects themselves.
not sure what your removal callbacks are used for. typically caches allow
removal of any object at anytime, to allow cache pruning.
switching to a Singleton is just a design pattern (static method to access
object), it does not change your locking issues, you still need to handle
these.
-- bruce (sqlwork.com)
"William Sullivan" <WilliamSullivan@.discussions.microsoft.com> wrote in
message news:D0527EBA-8DAD-464E-92AA-558F32F4AE44@.microsoft.com...
> I'm trying to nail down some issues with the cache in my application.
> Currently, I have an object that stands between my business logic and
> database logic called CacheLogic (cute, no?). Global.asax.cs creates it
> in
> Application_Start, initializes it and places it in the cache. During
> initialization, CacheLogic retrieves data from the DB logic layer and
> caches
> it with removal callbacks set. Whenever an object in the business logic
> layer needs data, it grabs the CacheLogic object from the cache (that's a
> violation of the layer right there, I know), and requests the needed data
> from it. CacheLogic retrieves the data from the cache and returns it. If
> the
> data is not in the cache, it retrieves the data from the database logic
> layer, caches it (with removal callbacks), and then returns the data.
> I'm concerned about what happens when two clients are requesting the same
> data at the same time when that data is not in the cache. Right now, as I
> understand it, CacheLogic will hit the database and cache the data twice.
> I'm not sure what side effects that might have, so I'm trying to figure
> out
> ways to avoid this situation completely without killing performance (i.e.,
> lock(HttpContext.Current.Cache)).
> To make CacheLogic more thread safe, I can lock on a sync object in the
> class when I write to the cache or use Mutex. But what use is that unless
> I
> also lock when I read from the cache? And isn't that just as bad as
> locking
> the cache object itself?
> The other issue I have is that CacheLogic stores objects in the cache with
> removal callbacks pointing to methods in the CacheLogic object. If I
> create
> CacheLogic objects willy-nilly, I could end up with multiple objects in
> memory, referenced only by the callback in some cache object. Sounds too
> close to a memory leak for me. Currently, by storing a single CacheLogic
> object in the cache itself, I have one single object that handles caching
> and
> callbacks for all client connections. I'm not happy that in order to get
> the
> CacheLogic object, other objects have to violate the layers and access the
> cache directly.
> Do I even need to worry about keeping a single CacheLogic object? Is
> converting CacheLogic into a singleton (is there an ISingleton interface?)
> a
> good solution to this problem? And, if I do, once I use the CacheLogic
> singleton in Application_Start (assuming I code it properly), will it be
> truly available to all clients who call CacheLogic.GetInstance()?
>