Abstraction Issue

[Cody]

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_PAR TS". Assembly C simply knows
the data as myInfo.ItemCoun t. Now, if Assembly C logs an error, it
will only know to log something like "error processing
myInfo.ItemCoun t". What would be nice is if Assembly C knew where
ItemCount came from and therefore could log something like "error
processing myInfo.ItemCoun t which came from database XYZ, Table 123,
Field "NUM_OF_PAR TS" 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.

[Bruce Wood]

Re: Abstraction Issue

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.

[Nicholas Paldino [.NET/C# MVP]]

Re: Abstraction Issue

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]
- mvp@spam.guard. caspershouse.co m

"Cody" <codym04@yahoo. com> wrote in message
news:1133384939 .301148.101540@ o13g2000cwo.goo glegroups.com.. .[color=blue]
> 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_PAR TS". Assembly C simply knows
> the data as myInfo.ItemCoun t. Now, if Assembly C logs an error, it
> will only know to log something like "error processing
> myInfo.ItemCoun t". What would be nice is if Assembly C knew where
> ItemCount came from and therefore could log something like "error
> processing myInfo.ItemCoun t which came from database XYZ, Table 123,
> Field "NUM_OF_PAR TS" 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.
>[/color]

[Kevin Spencer]

Re: Abstraction Issue

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" <codym04@yahoo. com> wrote in message
news:1133384939 .301148.101540@ o13g2000cwo.goo glegroups.com.. .[color=blue]
> 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_PAR TS". Assembly C simply knows
> the data as myInfo.ItemCoun t. Now, if Assembly C logs an error, it
> will only know to log something like "error processing
> myInfo.ItemCoun t". What would be nice is if Assembly C knew where
> ItemCount came from and therefore could log something like "error
> processing myInfo.ItemCoun t which came from database XYZ, Table 123,
> Field "NUM_OF_PAR TS" 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.
>[/color]

[Cody]

Re: Abstraction Issue

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.

[Cody]

Re: Abstraction Issue

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.