On 10-06-29 12:05 PM, Justin Harris wrote: 
----- "Ajay Kumar" <ajaykumarns@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@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@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@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin

        


--
Devan Goodwin <dgoodwin@rm-rf.ca>
http://rm-rf.ca
_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin

      


-- 
with regards
     Ajay
http://www.linkedin.com/in/ajaykumarns
_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
    
_______________________________________________
candlepin mailing list
candlepin@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