Accessing Class / Circular Reference

[George Durzi]

Consider these three projects:

- ProjectWeb (my web application)
- Facade (my class library, does data access, etc.)
- Library (a library of classes I reuse in applications)

ProjectWeb references Facade, and on login adds an instance of a
Facade.UserInfo class (a User class) into the user's Session. The session is
called Session["User"], and I can reference the UserInfo properties by
doing: ((UserInfo)Session["User"]).UserId or
((UserInfo)Session["User"]).UserName, etc.

Both ProjectWeb and Facade reference the Library project, as it contains all
the error logging code. (An implementation of Microsoft's ExceptionManager
application block)

In the Library class, there's an error logging class that needs the current
user's UserId in order to write a record into the error log table. I'd like
to grab this from the UserInfo instance that's in Session. I have access to
HttpContext.Current.Session["User"], but I have to cast the object to
UserInfo in order to access it's properties.

Ideally, I would access the UserId property like this:
HttpContext.Current.((UserInfo)Session["User"]).UserId

However, I can't do that because Library would have to reference Facade
(circular reference) in order for me to have access to the UserInfo class in
my code.

Any suggestions on how to do this, without having to create new Session
variables for the UserId?

Thanks!

[Phillip Ian]

If your Library needs to reference an object in Facade, is it really
reusable in other applications? By storing the ID (specific to this
app), you're further making Library application specific.

I think those "violations" are what are causing your headache.

The simple fix I can see is to pass the UserID into the "write an
error" routine in library. Then it doesn't have to know anything about
the Facade.UserInfo class.

The more complex fix is to make a "BaseUserInfo" class in Library.
Define it MustInherit (not sure if this is the same keyword in
C#...that's how we'd do it in VB), and include in it anything that
Library needs to know about a user to do its job. Then you can extend
that class in Facade, and add any application specific things to it,
but still pass a user to Library.

As usual, someone else probably has a better idea, but there's my
$0.02. :)

[George Durzi]

Thanks Phillip,
You're right about the "violations". Having it access something in the
UserInfo class would kill this reuse.

The error insert function is part of a class that inherits from
IExceptionPublisher (from Microsoft's ExceptionManager application block),
so I might try to modify that to take in a UserId.

If I can't change that method signature, I will opt to go with the
BaseUserInfo solution.

Thanks again Phillip

George

"Phillip Ian" <ph****@comcast.net> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

If your Library needs to reference an object in Facade, is it really
reusable in other applications? By storing the ID (specific to this
app), you're further making Library application specific.

I think those "violations" are what are causing your headache.

The simple fix I can see is to pass the UserID into the "write an
error" routine in library. Then it doesn't have to know anything about
the Facade.UserInfo class.

The more complex fix is to make a "BaseUserInfo" class in Library.
Define it MustInherit (not sure if this is the same keyword in
C#...that's how we'd do it in VB), and include in it anything that
Library needs to know about a user to do its job. Then you can extend
that class in Facade, and add any application specific things to it,
but still pass a user to Library.

As usual, someone else probably has a better idea, but there's my
$0.02. :)