On 10-06-29 12:05 PM, Justin Harris wrote:
----- "Ajay Kumar"<ajaykumarns(a)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(a)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(a)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=9898dccdb...
>
>>> _______________________________________________
>>> candlepin mailing list
>>> candlepin(a)lists.fedorahosted.org
>>>
https://fedorahosted.org/mailman/listinfo/candlepin
>>>
>>>
>>
>>
>> --
>> Devan Goodwin<dgoodwin(a)rm-rf.ca>
>>
http://rm-rf.ca
>> _______________________________________________
>> candlepin mailing list
>> candlepin(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/candlepin
>>
>>
>
>
> --
> with regards
> Ajay
>
http://www.linkedin.com/in/ajaykumarns
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/candlepin
>
_______________________________________________
candlepin mailing list
candlepin(a)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