What goes in Resources?

Dmitri Dolguikh dmitri at redhat.com
Tue Jun 29 16:03:56 UTC 2010


On 10-06-29 12:05 PM, Justin Harris wrote:
> ----- "Ajay Kumar"<ajaykumarns at gmail.com>  wrote:
>
>    
>> I agree with Devan's view that,
>>
>>   *) There should be a separate middle layer which takes care of
>> business logic
>>        - One of the issues I faced when implementing the FIFO/LIFO
>> functionality is that, I had to interact with different curators.
>>           In my case PoolCurator and EntitlementCurator. Since the
>> refresh functionality was implemented within the PoolCurator,
>>        I had to write criteria queries within the PoolCurator class
>> instead of EntitlementCurator(Ideally all entitlement CRUD should be
>> done here). The later creates a cycle of dependencies between
>> different curators which ideally should not happen and should be
>> avoided. Another thing I would like to point out is that throughout
>> our code base, a lot of hibernate dependencies is sprinkled. I do not
>> know whether this would cause problems in the future.
>>
>>   *) The resource layer should delegate the call to the respective
>> business layer so that the number of dependencies will go down.
>>            All business logic can be implemented here. It focuses the
>> functionality to a single layer and also makes it easy to co-ordinate
>> between different curators.
>>
>> An unrelated concern I have is about the junit test cases in
>> candlepin. Should the test cases not be in the same package as the
>> class they are testing? (Right now, all test cases are in
>> com.fedoraproject.candlepin.*.test) .The idea is that you can test
>> protected methods if they are in the same package.
>>      
> +1 to this.  I have actually been curious about that myself...
>
>    
>>
>>
>> On Tue, Jun 29, 2010 at 10:26 AM, Devan Goodwin<dgoodwin at rm-rf.ca>
>> wrote:
>>      
>>> Additionally, events are only thrown in resources currently. (IIRC)
>>>
>>> Kind of a tough one, we don't have clear lines drawn.
>>>
>>> I think the initial plan was curator = business logic and database
>>> access all in one.
>>>
>>> I really don't know if we should do:
>>>
>>> - resource = pure rest layer, new middle layer = business logic,
>>> curator = db access.
>>> - resource = pure rest layer, curator = business logic + db access
>>> - resource = business logic, curator = db access
>>>
>>> On Tue, Jun 29, 2010 at 10:30 AM, Bryan Kearney
>>>        
>> <bkearney at redhat.com>  wrote:
>>      
>>>> I have had  question about how fat resources should be. I am going
>>>>          
>> to
>>      
>>>> pick on Ajay (sorry) because I was looking at his patch for the
>>>> LIFO/FIFO Stuff (good job).
>>>>
>>>>
>>>> In his patch [1] he has added the revocation code into the Owner
>>>> Resource. Should this actually be in the curator level? There are
>>>>          
>> other
>>      
>>>> example of this (ConsumerResrouce.create adds the identity
>>>>          
>> certificate)
>>      
>>>> as well.
>>>>
>>>> My main question is, should the resource be "only" going from REST
>>>>          
>> to
>>      
>>>> internal API? Or should there be business logic there?
>>>>
>>>> -- bk
>>>>
>>>>
>>>> [1]
>>>>
>>>>          
>> http://git.fedorahosted.org/git/?p=candlepin.git;a=commitdiff;h=9898dccdb62806e4d721c160ac702b6958c427a4
>>      
>>>> _______________________________________________
>>>> candlepin mailing list
>>>> candlepin at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/candlepin
>>>>
>>>>          
>>>
>>>
>>> --
>>> Devan Goodwin<dgoodwin at rm-rf.ca>
>>> http://rm-rf.ca
>>> _______________________________________________
>>> candlepin mailing list
>>> candlepin at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/candlepin
>>>
>>>        
>>
>>
>> -- 
>> with regards
>>       Ajay
>> http://www.linkedin.com/in/ajaykumarns
>> _______________________________________________
>> candlepin mailing list
>> candlepin at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>      
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>    
Hey all,

A few thoughts on models, resources, and other related issues.

- Curators live in model package, and that is by intent - they are 
model. In the ideal world I'd prefer to have a very rich model with 
objects knowing how to persist, update, etc themselves. While this is 
possible (supposedly) with IoC's such as Spring, it's slow and not 
without problems. Which leaves us something in between (I'm also not a 
fan of anemic models where all business logic is concentrated in the 
service layer) - split business logic between entities and curators. It 
seems that at the moment we are mostly dealing with db, so it might be 
the reason why we have so much stuff in curators.

- resources, imho are not part of the model, but rather stuff that 
interfaces entities with http, you know, things responding to http 
verbs, like encoding, content type, etc. Another role that resources can 
play is orchestration of calls - one resource can deal with multiple 
entities/curators in order to produce a result.

these responsibilities are a bit vague, but do give an idea for 
separation of concerns.

re: tests - need a bit of cleanup and changes to package names is 
certainly one of the things. bryan, would it be ok if i add a story to 
the backlog, so this doesn't get lost?

-d

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/candlepin/attachments/20100629/95ceba87/attachment.html>


More information about the candlepin mailing list