Say you were to develop a system which availability of entities and domain logic is highly dependent on user context. Would it make sense to handle the user context sensitivity within repositories by making individual repository instances user context aware? I'm considering adopting this methodology as a way pulling the reliance on user context away from my Entities but I'm not sure whether there are any pitfalls that I may not be aware of with going this direction. The way I'm planning approaching this first is to add a UserContext parameter to the constructors of repositories that need this context information. The other obvious option would be to feed user context information into each query method in my repositories but this would likely mean that the majority of all methods would require such parameter which would in turn greatly increase the verbosity of each method call.
Also I would like to point out that I'm aware that even if I am to make repositories user context aware that this does not necessarily help directly when a service or entity needs that same user context information for reasons such as determining behavior based on user configuration. I'm interested in other solutions for these cases as well but for now I'm trying to tackle one thing at a time so I'm focusing on the repositories first.
Any suggestions would be appreciated.
I sense a design smell here :-). Things by the time they reach domain layer should pretty much be translated into domain entities/attributes and should not have dependency on context. What I mean is the context should be used to change/represent the new state of entity. Here it more seems like that context is going to be used to determine how the entity is going to be persisted. Have I understood this correctly?
Having said that, if your dependency on context is more from an infrastructure perspective rather than business functionality perspective then having context sensitive Repositories is the right model you have come up with.
Towards that, could you consider passing usercontext through thread local like Spring does with Hibernate Session? This way your Repository class's constructors or methods would be less polluted. It, however, does reduce the readablility of your code a bit.
Hope that helps.