2

I'm started to look at both the API and BAO classes.

It seems there is a degree of scope overlap for the business logic.

It seems to me that most logic should live in the BAO - but am I missing something? When does logic belong in the API but not in the BAO?

1 Answer 1

2

The API should really only apply logic that can be derived from the metadata - ie. the api applies defaults, enforces required fields, maps names of option values to the values.

Any logic that is 'business logic' should be in the BAO. ie. the api should be a thin layer over the BAO on the create & delete functions & anything other than GET (where the BAO can basically be considered to be deprecated where GET type functions exist).

In addition the api layer has the function of providing compatibility - ie. if a field name changes it is up to the api layer to make this seamless to api users. Realistically this could also be done via metadata in the xml and perhaps that fact explains why it is in the api layer. The api.aliasing, for example, is currently declared in the api but could be declared in the xml. The compatibility functionality should be reset when the version increments (perhaps an argument for keeping the metadata in the api)

2
  • 1
    I wonder who user4278 is?? Feb 7, 2017 at 5:14
  • 2
    Wish I could upvote @ErichBSchulz 's comment.
    – JohnFF
    Feb 7, 2017 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.