8:30 a.m.
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...
9:26 a.m.
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
9:48 a.m.
----- "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
Personally, I prefer option 1, but I tend to prefer smaller classes.
Having said that, I'm not too opinionated on this, except that I do agree
that we should have some consistency.
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
9:58 a.m.
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.
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
10:05 a.m.
----- "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
11:03 a.m.
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
9:03 a.m.
On Tue, Jun 29, 2010 at 11:58 AM, 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.
Sounds like most are in favor of a new layer in the middle for
business logic. I'm not positive this totally solves the circular
dependency problem, it will probably surface again even with three
layers, but in any case it should be much less frequent. We should get
a prototype out there, something we can code to as we go.
Cheers,
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
6:24 a.m.
On 07/05/2010 10:03 AM, Devan Goodwin wrote:
On Tue, Jun 29, 2010 at 11:58 AM, 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.
>
>
>
Sounds like most are in favor of a new layer in the middle for
business logic. I'm not positive this totally solves the circular
dependency problem, it will probably surface again even with three
layers, but in any case it should be much less frequent. We should get
a prototype out there, something we can code to as we go.
Any disagreements? FWIW.. I like making the model DB only as it may let
us play with Mongo :)
-- bk
8:35 a.m.
----- "Bryan Kearney" <bkearney(a)redhat.com> wrote:
On 07/05/2010 10:03 AM, Devan Goodwin wrote:
> On Tue, Jun 29, 2010 at 11:58 AM, 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.
>>
>>
>>
>
> Sounds like most are in favor of a new layer in the middle for
> business logic. I'm not positive this totally solves the circular
> dependency problem, it will probably surface again even with three
> layers, but in any case it should be much less frequent. We should
get
> a prototype out there, something we can code to as we go.
>
Any disagreements? FWIW.. I like making the model DB only as it may
let
us play with Mongo :)
SHIPIT
-- bk
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
7:39 a.m.
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
-1 to option 3
jesus
7:38 a.m.
I think the resources should handle all RESTy type stuff but it should pass that
logic off to some other layer IMO.
jesus
On Tue, Jun 29, 2010 at 9: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
5047
days inactive
5054
days old
candlepin@lists.fedorahosted.org
10 comments
6 participants
participants (6)
-
Ajay Kumar -
Bryan Kearney -
Devan Goodwin -
Dmitri Dolguikh -
Jesus M. Rodriguez -
Justin Harris