0

I have a FuelPHP application with a hierarchic user structure broken into two tiers, corporate and store. The application includes a ticketing system that allows custom fields.

Custom fields can be defined at the corporate level AND/OR the store level.

Custom fields that are defined at the corporate level serve as "default" custom fields. That is, any store within the purview of the corporation which HAS NOT overridden the "default" custom fields will have access to those custom fields.

Custom fields that are defined at the store level can either:

  1. Override a "default" (corporate level) custom field
  2. Act as an additional store level custom field that is not defined at the corporate level

Yesterday I wrote the logic to determine the correct fields for a store. It fetches all of the defined custom fields from the database, runs a few comparisons, and spits out an array of custom fields that are appropriate to the store scope.

I initially wrote the logic in my Fields controller, but today I realized that I need access to that data from other areas in the application, often times when there is no instance of the Fields controller available (without explicitly creating one).

I generally shy away from putting a much logic in my data models, mainly because I'm not sure when it's appropriate. However, in this case I re-wrote the logic statically and put it into my Field model as a for_store($id) method. It works, but I want to make sure I'm not doing something horribly wrong here.

Is this the kind of logic that you would put in a data model rather than a controller? My thinking is this: because it accesses data without manipulating it, yes, it belongs in the data model. Whereas if I were to actually change the data, it would belong in the controller. Does that make sense?

I'm interested in best practices from an MVC standpoint.

Ben Harold
  • 6,242
  • 6
  • 47
  • 71
  • 1
    Controllers should not any business logic to begin with. It all should reside in the model layer *(no, model is not any single class or object)*. Controller **only** responsibility is to alter state of model layer and (in much rarer cases) current view instance, based on user input. – tereško Aug 07 '13 at 00:02
  • 0 down vote I dont see why this would EVER be in the controller. This is inherently part of the data model because it id directly related to how the model operates and how the model persists its data. – prodigitalson Aug 07 '13 at 00:06

0 Answers0