471,317 Members | 1,638 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

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

Abstraction Issue

We have a situation where our adapter (Assembly A) gets data from a
database and gives the data to an internal service (Assembly B) which
then gives it to the client (Assembly C). By the time it reaches
Assembly C, the source information of where the data came from is lost.
In other words, Assembly A knows the data came from the database and
that the data item was called "NUM_OF_PARTS". Assembly C simply knows
the data as myInfo.ItemCount. Now, if Assembly C logs an error, it
will only know to log something like "error processing
myInfo.ItemCount". What would be nice is if Assembly C knew where
ItemCount came from and therefore could log something like "error
processing myInfo.ItemCount which came from database XYZ, Table 123,
Field "NUM_OF_PARTS" with SQL of "select * from....".

Any ideas on how to do this? What would be really nice is to inherit
from "int" and then add a source property. But "int" is a value type
and, therefore, is not like an object.

Nov 30 '05 #1
5 985
What is the class of myInfo (in your example)? Couldn't you put source
information at that level? After all, ItemCount probably wasn't the
only thing that was fetched from that table by that SQL query.

I see where you're going, but I think that the individual property
level is too low a level at which to store the kind of information you
want to keep. As you pointed out, ints can be passed all over the
place, and you certainly don't want to draw a fundamental distinction
between ints that came from the database and those that were calculated
on the fly... that would, I believe, cause you more grief in your code
than losing the information in the first place.

Nov 30 '05 #2
Cody,

Assuming that you have distinct wrappers for your data, why not place an
attribute on the property that is returning the value that you got from the
database? Then, you can use reflection to get the attribute, and then it
would have the information that you need about the database column/table.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Cody" <co*****@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
We have a situation where our adapter (Assembly A) gets data from a
database and gives the data to an internal service (Assembly B) which
then gives it to the client (Assembly C). By the time it reaches
Assembly C, the source information of where the data came from is lost.
In other words, Assembly A knows the data came from the database and
that the data item was called "NUM_OF_PARTS". Assembly C simply knows
the data as myInfo.ItemCount. Now, if Assembly C logs an error, it
will only know to log something like "error processing
myInfo.ItemCount". What would be nice is if Assembly C knew where
ItemCount came from and therefore could log something like "error
processing myInfo.ItemCount which came from database XYZ, Table 123,
Field "NUM_OF_PARTS" with SQL of "select * from....".

Any ideas on how to do this? What would be really nice is to inherit
from "int" and then add a source property. But "int" is a value type
and, therefore, is not like an object.

Nov 30 '05 #3
Perhaps Assembly A Could tell Assembly B, and Assembly B could tell Assembly
C.

Then Assembly C can tell two friends. And she can tell 2 friends. And so on.
And so on. And so on.

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

"Cody" <co*****@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
We have a situation where our adapter (Assembly A) gets data from a
database and gives the data to an internal service (Assembly B) which
then gives it to the client (Assembly C). By the time it reaches
Assembly C, the source information of where the data came from is lost.
In other words, Assembly A knows the data came from the database and
that the data item was called "NUM_OF_PARTS". Assembly C simply knows
the data as myInfo.ItemCount. Now, if Assembly C logs an error, it
will only know to log something like "error processing
myInfo.ItemCount". What would be nice is if Assembly C knew where
ItemCount came from and therefore could log something like "error
processing myInfo.ItemCount which came from database XYZ, Table 123,
Field "NUM_OF_PARTS" with SQL of "select * from....".

Any ideas on how to do this? What would be really nice is to inherit
from "int" and then add a source property. But "int" is a value type
and, therefore, is not like an object.

Nov 30 '05 #4
This is a good idea. I'm trying to make it so that the developer is
abstracted from seeing or dealing with Source information as much as
possible. Therefore, how could I get something like this working:

logUtility.Log(@"NumOfDie value is not handled by the ToolSetup()
method.", Lot.NumOfDie);

Note how the developer using my framework simply creates the error
message and then passes the property that caused the issue via a
parameter array type arugument.

Dec 1 '05 #5
I like this idea. The only issue is that it's not dynamic therefore
Assembly C needs to have source infomation hard coded as a part of it's
attributes.

Dec 1 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Ruby Tuesday | last post: by
21 posts views Thread by ambika | last post: by
30 posts views Thread by Luke Wu | last post: by
25 posts views Thread by Colin McKinnon | last post: by
2 posts views Thread by Eric Cathell | last post: by
1 post views Thread by rickycornell | last post: by
8 posts views Thread by Ivan S | last post: by

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.