conceptual/architectural advice needed

conceptual/architectural advice needed

Old forum URL: forums.lhotka.net/forums/t/8687.aspx


vschaak posted on Thursday, March 18, 2010

Hi,

my first CSLA-project's near to completition and I want to add a "small" functionality which worked out to be a little more complex than thougth at first:

I's about a tool for user-/permission-management. It knows users, roles and permissions. Users and roles could be edited by users(admins in this case), permissions are fixed, since they are used in the main-apps and therefore only to be defined by the developers. Users can have n-roles and even n-permissions can be assigned to users. It all works and even vice versa (i.e. not only "What roles is a user assigned to?", but also "Which users are assigned to a certain role?") A little like PTracker's Project/ressource relationship, only with three actors.

Now it get's a little more complex: Permissions could be hierachical. That means, if a user (or role) has the permission "editWidget" he should be granted "viewWidget" automatically. The main apps-application Identity-object reflects that through it's fetch method, since the called sproc retrieves a list (based on a self-linked table in DB), incorporating the inherited permissions. Now, in the managment app I want to show the users which permissions they EFFECTIVLY assigned to a user when assigning "deleteGadget". For that it should'nt be afforded to retrieve the self-linked-list from the DB more than once, since it never changes(s.above)!
But how to handle this list to the BO's (without unneccessary db-connects) and how to hook the algorithm to recalc the effective Permissions to the BO? Is it odd to handle the list through the factory methods and give it to the fetch methods thereafter?

Not sure...

Greetings

Volker

ajj3085 replied on Thursday, March 18, 2010

I don't think this will be as simple as you think.  But to get an idea of where start, I think this blog post from Rocky is very useful.

vschaak replied on Thursday, March 18, 2010

Hi Andy,

thank you for your time.

I know Rocky's blog post quite well. Unfortunatly this isn't my problem at all! For authorization/authentification issues I wrap my permissions into the principals IsInRole method, which works fine. Those a/a issues are solved, so no prob over there. Those objects are totally different from those used in the user-management-app (although they retrieve their info from the same db-Table)

In short my prob is how to create a list off hierachical structured elements, in this case all inherited permissions that are implicitly assigned. The linked-list (two fields: permission, inheritedPermission) should be retrieved only once from the db, since it never changes.

Any idea?

Thx for any help.

Volker

RockfordLhotka replied on Saturday, March 20, 2010

vschaak

In short my prob is how to create a list off hierachical structured elements, in this case all inherited permissions that are implicitly assigned. The linked-list (two fields: permission, inheritedPermission) should be retrieved only once from the db, since it never changes.

So this information is not user-specific, and it needs to be loaded once and cached for the life of the application?

You can use a ReadOnlyBase or ReadOnlyListBase object to get the data and put it into Csla.ApplicationContext.LocalContext if that's the case.

vschaak replied on Sunday, March 21, 2010

Hi Rocky,

exactly that's the way it is! This list definitly never changes, since we (the developers) define the permissions, so that loading it once in a lifetime of the app's session fits the need.

Are objects, stored in LocalContext accessible from my BO's directly? Then it would be the right place for the list...

Is there any sample of how to use LocalContext in PTracker or the other app's you can point me to?

Thanks for answering and greetings over the big pond

Volker

RockfordLhotka replied on Sunday, March 21, 2010

LocalContext is much like ASP.NET Session:

Csla.Application.LocalContext is a dictionary that is maintained for you and is globally accessible to all code in your thread (it is stored per-thread, or (I think) in WPF it is per-AppDomain and for sure on Silverlight it is per-AppDomain).

The only thing to watch for is events. If something handles an event from your object, that means your object has a reference to whatever is handling the event. Since your object wiill never go away (because it is in LocalContext), that reference will never go away, which means the listener won't go away. Obviously this is a horribly easy way to create a memory leak.

So be very careful not to hook any events from the list - either explicitly or implicitly (like through data binding).

vschaak replied on Monday, March 22, 2010

Hi Rocky,

well, that sounds good (at least at first sight Wink). My plan is that there will be a private method in my BO (so not in the never changing list), which references the list, generating the effective list through recursion and writing these to a property in the BO. This method will be hooked to events of the BO, not the list stored in LocalContext.
This should work, without danger of creating memory leaks, shouldn't it?

Unfortunatly PTracker doesn't include a sample of using this dictonary. What type of objects can be stored there? What to take care of?

Kind regards

Volker

RockfordLhotka replied on Monday, March 22, 2010

If I remember right it is a Dictionary<string, object>, or maybe <object, object>. So it is pretty standard.

vschaak replied on Sunday, March 21, 2010

Hi Dan,

thanks for answering.

Yes, I need a method like this, and it would be private, so it has to populate he ListOfEffectivePermission. It will be executed at fetching and oher events, that changes users roles and/or diectly assigned permissions (which together result in he EffectivePermissions). The implementation of this method should be almost trivial...

Greetings

Volker

Copyright (c) Marimer LLC