I am working on a my first CSLA app and in using some of my logic I think there might be a way for CSLA.Net to use a version of it....
my current user (IIdentity/IPrincipal) class as an extra feild "ID" this is the key in my "Employees" table; an Int.
other tables all have WhoCreated and WhoChanged that are Int and related to Employees.
see where this is going? if the data save/update/create logic could pick up that ID on-the-fly and pass it back to the database then records would automaticaly get updated on who editied them.
I am sure I can make this work for me by coding it one time for my app but I am thinking there might be some way to specify to the BO framework that it should add that ID w/o the manual code.
for a general solution I guess it would need to work with other data types like string, guid etc...
also my logic puts the sql servers date-time into the record so later we can see:
Who Created and CreationTimeStamp - who and when the row was inserted, Read Only after that.
WhoChanged, LastChanged - who last updated the row, and when.
this helps track edits and gives a base for creating a full audit trail if needed.
I do that in SQL with triggers if and when needed.
Hi,
These are all good ideas. I have implemented most of them in CSLA. My custom Principal class had ID plus more information for each user. I use the ID constantly in the app. For the Inserts and Updates the ID is used for just the reasons you state. I do not have a generalized solution. I codegen my Base classes and this is a standard part of my templates.
Joe
Yeah I am using CodeSmith and finding out what and where I need to make adjustments to stuff.
and I do have a few other things in my user-info I am taking it a step at a time as I do not want to de-stablilize rocky's framework with random crap changes :-)
also I have my "employees" table with the login and first thing I saw in the sample app was the plain-text password; not in my production system!!!
so I have a salt and hashed-password in my db and I have things arranged so that the plain-text password should never leave the local pc. I have a sql proc GetSalt that takes the username and gives back the ID and the Salt, username is uniqe in the table.
then I can hash the password and call a Login proc with the ID and the hash.
that way username travels 1 time and hash travels 1 time. never both ways.
and when the password is updated it gets new Salt so even if more than one user has the same plain-text password I should never see two hashed passwords with the same hash.
also I do not delete a row, I mark it as not-active
then later I can delete it if there are no reasons to keep it.
that also helps with the basis of an audit trail.
Copyright (c) Marimer LLC