Dynamic Proxy Integration

[jnoody]

Sorry for the non-descriptive subject, but I'm not exactly sure how to
title this. Also, I apologize that this is also largely a concept and
design problem that, while I'm hoping I can get some guidance into how
to solve my problem using LinFu, is not really a LinFu issue (any
advice, LinFu-related or not, would be appreciated). I also apologize
for the length of this message, but I feel I should describe the issue
fully because I don't know enough to ask the write the right questions
(I don't know what I don't know).

I'm creating a component to manage permissions between two arbitrary
entities in a domain. I'd like to do this in such a manner that
instances of my entity classes have seamless access to lists of their
permissions. I'm going to use the term "permission owner" to refer to
the end of the permissions relationship that is being given authority
and "permission object" to refer to the end that a permission owner is
being given permissions on. For example, if I want to give a user
permission to a file, then user is the permission owner and file is
the permission object. For now, assume that there is only one single
type of permission. An owner either has permission to an object, or
not. My permissions domain essentially consists of the following
classes and interfaces (there are actually some generic type
constraints required to make this compile, but that seems way to
verbose for here right now):

public class Permission<OwnerT, ObjectT>
{
public OwnerT Owner
{
get;
set;
}

public ObjectT Object
{
get;
set;
}
}

public interface IPermissionRepository<OwnerT, ObjectT>
{
void Save(Permission<OwnerT, ObjectT>);

List<Permission<OwnerT, ObjectT>> GetAll();
}

The IPermissionRepository is used by the UI and such as an injectable
persistence class.

So the big question is this, how can I set it up so that the instances
of "OwnerT" and "ObjectT", which are defined in the namespace of the
consumer of the permissions component, can access the Permission
instances that belong to them?

I've some ideas about this, but so far they all require the consumer
of the permissions component to have a dependency to a specific proxy,
persistence, or persistence mapping implementation. Any help would be
appreciated. Thank you.

[Philip Laureano]

Hi jnoody,

If the problem is that you don't want to bind yourself to a specific proxy library, then you could always work against a set of proxy interfaces that abstract away the details of whatever dynamic proxy implementation you might be using. AFAIK, Ninject1 uses this approach to avoid binding itself to both LinFu and Castle, and from what I can tell, that approach seems to work well for them. You could try that approach and see how it works. As for your second problem, I'm not entirely sure if I understand what you're trying to do but it seems like you want to create an association between the OwnerT and ObjectT and their attached permission so that you can relate one back to other, and vice versa.

A simple way to do this would probably to have them implement some interface like IPermissionHolder:

public interface IPermissionHolder<OwnerT, ObjectT>
{
     Permission<OwnerT, ObjectT> Permission { get; set; }
}

...and in your Permission and Repository classes, you can just modify the OwnerT and ObjectT type constraints so that the type must implement IPermissionHolder<OwnerT, ObjectT> to be associated with a given permission. Does that help?

[jnoody]

I will look into Ninject and get back to you. I didn't totally
understand everything you said.

As far as my second issue goes (it was really just a reiteration of
the entire problem I'm trying to solve. I've implemented interfaces
similar to what you describe., but am not sure of the best guideline
for helping the consumer implement it. So let's say that the
consuming domain has a User entity class. The consumer would probably
want to create a new class that derives from the User class and
implements the IPermissionHolder interface. I suppose there would
need to be a way to inject an IPermissionRepository into the user
entity instances, as well. Is the above a good requirement: that the
consumer must code this? Or is there an easier way to allow the
consumer to integrate the permissions component into their domain?
And, of course, the User class could not be sealed (I can live with
that as a condition).

Another idea I've had is to force the consumer to instantiate their
entity classes using a proxy factory of some kind that requires the
entity types be specified along with the IPermissionHolder interface.
But then what if they are already creating instances using their own
proxy implementation? Is there a way to provide some sort of
integration without knowing their proxy implementation? Also, what if
they are consumer other components similar to this one (if I like my
design, I will end up using it for other components for sure) that
also require proxies. Is there a way to aggregate all these proxies
together?

It's probably a pipedream, but what I'm really looking to do is give
the consumer a way to run some configuration that forces (at runtime?)
instances of their entity classes (even if they are created using
"new") to have a way to call up the permissions that it holds. Short
of that, I'm looking for an easy configuration on the consumer's part
(don't have to write a lot of code, don't have to edit complex
NHibernate-type mappings, etc.)

Btw, I like the term "holder" a lot more than "owner" that I've been
using. Thanks.

[jnoody]

I'm starting to think that a true AOP framework is what I'm going to
need. Something like PostSharp or Cecil?

[Philip Laureano]

Yeah, but from the looks of it, it might be overkill for what you need.

[jnoody]

Meaning that AOP will accomplish what I want to do the way I want to
do it, but the way I want to do it is overkill for what I want to do?
Or that AOP is overkill for the way I want to do it?

[Philip_L]

TBH, I'm not entirely sure what you're trying to accomplish here (at
least from an end user's standpoint). As a matter of design principle,
I always choose the option that ensures a minimal amount of effort on
the part of the end user. AOP is great and everything, but like any
other tool, it can bring more harm than good if you find that it makes
the solution complicated than it needs to be. In your case, it seems
like you want to implement permissions through AOP, but if you end up
forcing the user to conform to your model (instead of having to
conform to their use cases), that makes things more complicated than
it needs to be, and that's why I call it overkill.

Forcing the user to do a DIY approach (IMHO) is not a good idea. The
only advice that I can give you is that you try to prototype these
permissions using standard programming practices (such as structured,
OOP, etc) and then see how you can use AOP to make the approach easier
to maintain and use for the end user. In other words, you can always
try writing it without any AOP code and just refactor it with AOP once
you get it working instead of trying to design everything up front.
That should save you a lot of time with the design since you'll only
be refactoring code that will actually be used instead of possibly
speculating on what may or may not be a good design and end up with
code that won't be used at all.

If you do decide to stick with the AOP approach, then you have to make
sure that it's easy to understand since AOP (by its very definition)
is not something that is easy to grasp for many developers. Anyway, I
hope this helps. :)

Regards,

Philip Laureano