I need to make sure certain constrains are applied to all my queries:
1) Every user in the system can see certain clients only, so every
query should only return documents for those clients.
2) Every user is in a role, if you are in the lowest role you can only
see the documents you created/
In the very first stage of this project I implemented this by using
the repository pattern and made sure this concerns were handled in the
base repository.
I had an horrible experience with this pattern and the worst part
about sharing this base queries is the impossibility of using specific
indexes if your queries are built upon this base queries.
So the question is, what is the best practice to deal with this cross
cutting concerns?
On Friday, 1 June 2012 17:22:31 UTC+1, racielrod wrote:
> Hello,
> I need to make sure certain constrains are applied to all my queries:
> 1) Every user in the system can see certain clients only, so every > query should only return documents for those clients. > 2) Every user is in a role, if you are in the lowest role you can only > see the documents you created/
> In the very first stage of this project I implemented this by using > the repository pattern and made sure this concerns were handled in the > base repository. > I had an horrible experience with this pattern and the worst part > about sharing this base queries is the impossibility of using specific > indexes if your queries are built upon this base queries.
> So the question is, what is the best practice to deal with this cross > cutting concerns?
> I need to make sure certain constrains are applied to all my queries:
> 1) Every user in the system can see certain clients only, so every
> query should only return documents for those clients.
> 2) Every user is in a role, if you are in the lowest role you can only
> see the documents you created/
> In the very first stage of this project I implemented this by using
> the repository pattern and made sure this concerns were handled in the
> base repository.
> I had an horrible experience with this pattern and the worst part
> about sharing this base queries is the impossibility of using specific
> indexes if your queries are built upon this base queries.
> So the question is, what is the best practice to deal with this cross
> cutting concerns?
While this would be a great fix for the scenario I described above I'm more interested on addressing common query concerns w/o having to repeat them over and over again. In order to walk away of the authorization context I put as an example above, let's use another examples:
What if a set of pre-conditions are part of certain group of queries. For instance, for certain department they only need to deal with documents with the following characteristics:
1) Users are older than 18 yo. 2) Females. 3) Approved. 4) Living on certain area: state, city, etc... ... n)...
What if you have several queries that use those pre-conditions; I don't want to repeat over and over the where clauses in my queries.
> On Friday, 1 June 2012 17:22:31 UTC+1, racielrod wrote:
>> Hello,
>> I need to make sure certain constrains are applied to all my queries:
>> 1) Every user in the system can see certain clients only, so every >> query should only return documents for those clients. >> 2) Every user is in a role, if you are in the lowest role you can only >> see the documents you created/
>> In the very first stage of this project I implemented this by using >> the repository pattern and made sure this concerns were handled in the >> base repository. >> I had an horrible experience with this pattern and the worst part >> about sharing this base queries is the impossibility of using specific >> indexes if your queries are built upon this base queries.
>> So the question is, what is the best practice to deal with this cross >> cutting concerns?
> While this would be a great fix for the scenario I described above I'm
> more interested on addressing common query concerns w/o having to repeat
> them over and over again.
> In order to walk away of the authorization context I put as an example
> above, let's use another examples:
> What if a set of pre-conditions are part of certain group of queries. For
> instance, for certain department they only need to deal with documents with
> the following characteristics:
> 1) Users are older than 18 yo.
> 2) Females.
> 3) Approved.
> 4) Living on certain area: state, city, etc...
> ...
> n)...
> What if you have several queries that use those pre-conditions; I don't
> want to repeat over and over the where clauses in my queries.
> On Friday, June 1, 2012 3:25:52 PM UTC-4, Matt Warren wrote:
>> Take a look at the Authorization bundle, it should handle these scenarios
>> for you, see:
>> On Friday, 1 June 2012 17:22:31 UTC+1, racielrod wrote:
>>> Hello,
>>> I need to make sure certain constrains are applied to all my queries:
>>> 1) Every user in the system can see certain clients only, so every
>>> query should only return documents for those clients.
>>> 2) Every user is in a role, if you are in the lowest role you can only
>>> see the documents you created/
>>> In the very first stage of this project I implemented this by using
>>> the repository pattern and made sure this concerns were handled in the
>>> base repository.
>>> I had an horrible experience with this pattern and the worst part
>>> about sharing this base queries is the impossibility of using specific
>>> indexes if your queries are built upon this base queries.
>>> So the question is, what is the best practice to deal with this cross
>>> cutting concerns?
On Friday, June 1, 2012 7:12:26 PM UTC-4, Oren Eini wrote:
> Raciel, > You have IDocumentQueryListener, which allows you to modify each query > before it is actually executed.
> On Fri, Jun 1, 2012 at 10:45 PM, racielrod wrote:
>> Thanks Matt,
>> While this would be a great fix for the scenario I described above I'm >> more interested on addressing common query concerns w/o having to repeat >> them over and over again. >> In order to walk away of the authorization context I put as an example >> above, let's use another examples:
>> What if a set of pre-conditions are part of certain group of queries. For >> instance, for certain department they only need to deal with documents with >> the following characteristics:
>> 1) Users are older than 18 yo. >> 2) Females. >> 3) Approved. >> 4) Living on certain area: state, city, etc... >> ... >> n)...
>> What if you have several queries that use those pre-conditions; I don't >> want to repeat over and over the where clauses in my queries.
>> On Friday, June 1, 2012 3:25:52 PM UTC-4, Matt Warren wrote:
>>> Take a look at the Authorization bundle, it should handle these >>> scenarios for you, see:
>>> On Friday, 1 June 2012 17:22:31 UTC+1, racielrod wrote:
>>>> Hello,
>>>> I need to make sure certain constrains are applied to all my queries:
>>>> 1) Every user in the system can see certain clients only, so every >>>> query should only return documents for those clients. >>>> 2) Every user is in a role, if you are in the lowest role you can only >>>> see the documents you created/
>>>> In the very first stage of this project I implemented this by using >>>> the repository pattern and made sure this concerns were handled in the >>>> base repository. >>>> I had an horrible experience with this pattern and the worst part >>>> about sharing this base queries is the impossibility of using specific >>>> indexes if your queries are built upon this base queries.
>>>> So the question is, what is the best practice to deal with this cross >>>> cutting concerns?
