How do you all manage an "update_user" column with your LLBLGen projects in a web form? Since at the server you're logged in as a single user, "current_user" (for SQL Server) doesn't really do what I want.

NickD wrote:

How do you all manage an "update_user" column with your LLBLGen projects in a web form? Since at the server you're logged in as a single user, "current_user" (for SQL Server) doesn't really do what I want.

You have to set the field in your object in the middle tier to the user name.

pilotboba wrote:

You have to set the field in your object in the middle tier to the user name.

Yep, and is anyone willing to share a nifty way they've done this? I guess what I'm getting at is how have people done this? My initial thoughts are that in my "SaveStuff" methods of my manager classes, I would set this property of the entities before calling the actual SaveEntity method, BUT, what are the ways people get this value in the BLL? Theoretically, the BLL will mostly be oblivious to the current user, right? What are some ways people share who the current user is with the BLL? If I am in a web context, then I can use Session, but what if I'm in a windows forms environment? I don't want to bind the BLL specifically to an httpContext.

In my opinion such information as "current user id" is clearly session-related information and as such you won't ever be really independent from your session handling mechanism on the server side.

I guess it depends a little on how you separate your server-side functionality. In our case we have two clearly separated tiers called "system services" and "business logic". The system services layer handles user sessions and transactions. Usually business logic methods have the DataAccessAdapter and user info as parameters if they need them.

That way at least only the system services layer is dependent on the session handling mechanism.

Example:

// business logic method
void SaveUserNameInSomeTable(UserInfo userInfo, IDataAccessAdapter adapter) {
   SomeTableEntity someTable = new SomeTableEntity();
   someTable.UserName = userInfo.Name;
   adapter.SaveEntity(someTable);
}

If you look at technologies more mature in the distributed systems area than .net, they usually have a "context" concept (I think COM+ has something like that too) where you can get context information from a predefined object, for example if your system services classes inherit from some base class. CORBA and J2EE have this concept, user sessions are handled in the base class and you inherit the "context" which contains session related info such as the current user id.

This is closely correlated to authorization & validation issues, i.e.: how do you know for sure who your user is.

Well anyway those were my 2 cents, hope it was of any use to you. cheers alvaro.-

NickD wrote:

pilotboba wrote:

You have to set the field in your object in the middle tier to the user name.

Yep, and is anyone willing to share a nifty way they've done this? I guess what I'm getting at is how have people done this? My initial thoughts are that in my "SaveStuff" methods of my manager classes, I would set this property of the entities before calling the actual SaveEntity method, BUT, what are the ways people get this value in the BLL? Theoretically, the BLL will mostly be oblivious to the current user, right? What are some ways people share who the current user is with the BLL? If I am in a web context, then I can use Session, but what if I'm in a windows forms environment? I don't want to bind the BLL specifically to an httpContext.

Assuming you are using forms or windows authentication you can get the username from the principal object of the thread in your BLL whether you are using Web forms or Windows forms.

System.Threading.Thread.CurrentPrincipal.Identity.Name

BOb

What we do is very similar to what others in this thread have said, except:

1. We ensure that every table in the database has an identical field named "CreatedByUserId" (we use an FK to the user table instead of a string name). We ensure this happens uniformly by using a script on every new table we create.

2. We derive a new class from DataAccessAdapter.

3. We force a "userInfo" object (we call it a "security" object) to be passed in as part of the derived DataAccessAdapter constructor.

4. We override the Save method on DataAccessAdapter.

5. In the override, we set the field's value whenever an entity is dirty or new (actually we have CreatedByUserId for new, UpdatedByUserId for dirty). We use "SetNewFieldValue", because it can set the value on any entity, regardless of type (no casting required).

I love having the ability to do this. It's kind of like a trigger, but much more flexible and easier to maintain.

Thread from when I was working on this myself: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=3224

Cheers,

Phil

psandler wrote:

Thread from when I was working on this myself: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=3224

Thanks for the link. In there, Frans mentions a (new to 1.0.2005.1) method in DataAccessAdapter called OnBeforeEntitySave, and I'm wondering if this is perhaps where I want to put this code. I would override this method and then in it, set the values of my update and insert user columns. Any gotchas to consider?