Client-Side Models – Should They Contain Foreign Keys?

The way I see this, it depends on what you intend to do with the data afterwards. Based on a few simple checks you can determine which of the two data structures is better for you:

1. Does this data have any logic associated with it?

   For example, is $price stored as an integer number of cents, so a product with a price of $9.99 would have price = 999 and not price = 9.99? (Probably, yes) Or does partNumber need to match a specific regex? Or, do you need to be able to easily check if the itemCount is available in your inventory? Will you need to do these these functions in the future? If so, then your best bet is to create a class now. This means that you can define constraints and logic built into the data structure: private $myPrice is set to 999 but $item->getPriceString() returns $9.99 and $item->inStock() is available to be called in your application.

2. Are you going to be passing this data to multiple PHP functions?

   If so, then use a class. If you're generating this data once to perform some transformations on it, or just to send as JSON data to another application (JavaScript or otherwise) then an array is an easier choice. But if you have more than two PHP functions which accept this data as a parameter, use a class. If nothing else, that lets you define someFunction(MyProductClass $product) { and it's very clear what your functions expect as input. As you scale out your code and have more functions it will be much easier to know what type of data each function accepts. Seeing someFunction($someArrayData) { is not nearly as clear. Also, this does not enforce type consistency and means that (as you said) the flexible structure of the array can cause development pain later on

3. Are you building a library or shared code base?

   If so, use a class! Think about some new developer who is using your library, or another developer somewhere else in the company who has never used your code before. It will be much easier for them to look at a class definition and understand what that class does, or see a number of functions in your library which accept objects of a certain class, than to try and guess what structure they need to generate in a number of arrays. Also, this touches on the data consistency issues with #1: if you're developing a library or shared code base, be nice to your users: give them classes which enforce data consistency and protect them from making errors with the design of your data.

4. Is this a small part of an application or just a transformation of data? Do you not fit into any of the above?

   A class might be too much; use an array if it suits you and you find it easier. As mentioned above, if you're just generating structured data to send as JSON or YAML or XML or whatever, don't bother with a class unless there's a need to. If you are writing a small module in a larger application, and no other modules/teams need to interface with your code, maybe an array is sufficient.

Ultimately, consider the scaling needs of your code and consider than a structured array might be a quick fix, but a class is a much more resilient and scalable solution.

Also, consider the following: if you have a class, and you want to output to JSON, there's no reason you can't define a json_data() method of your class which returns a JSON-ifiable array of the data in the class. This is what I did in my PHP applications where I needed to send class data as JSON. As an example:

class Order {
    private $my_total;
    private $my_lineitems;

    public function getItems() { return $this->my_lineitems; }
    public function addItem(Product $p) { $this->my_lineitems[] = $p; }
    public function getTotal() { return $this->my_total; }

    public function forJSON() {
        $items_json = array();
        foreach($this->my_lineitems as $item) $items_json[] = $item->forJSON();
        return array(
            'total' => $this->getTotal(),
            'items' => $items_json
        );
    }
}

$o = new Order();
// do some stuff with it
$json = json_encode($o->forJSON());

You've given scant details on your user base, but it sounds like you do not have a multi-tenant requirement. There are also few details into how your views differ between each other. On instinct, I would guess that you do not have mutli-tenant, but in fact have multiple groups. I would also guess that you are leaning towards a solution which will cause you to be angry with yourself later on. More specifically, separate implementations of each of the search view, grid view, and detail view.

I believe you should use standard user authentication via keystone, or keycloak, or another third party. Take advantage of their users / groups / roles to assign a hierarchy of permissions. Something like USER_BASIC_PERM would grant them access to an object's ID, Name, and Category. USER_CASH_PERM would grant then access to cost, value, profit margin. USER_ADMIN_PERM would let them see fields relating to 3rd party buyer, url to PO, etc. You can use groups to put mutliple role permissions together and manage users more easily with a single group.

Then you can build your three views by including / excluding sub-views based on the user's permissions. When they submit a search, you must validate their fields based on their roles server-side. When returning details, you must put it through a permission filter before returning it to the client. In the long run, this will be easier to maintain than implementing separate views for each of your tenants.

I think that if you consider that it's only permissions of a user that are the difference, then you'll see that the major functionality should be self-contained. 'search' would be one server-side module. Grid data access would be another. Keeping similar functionality together on the server-side will lead towards less repetition. Separating server-side by group would mean that you need to visit 3 separate modules to fix one bug that spans all of your 'grid' queries.

Think about long term - if you add 5 more tenants that are very close to the three you know about, which one will cause less pain to implement later.

Let's say you add a fourth view. Do you want to add it once with permission checks, or once for each of your now 8 tenants - even if most of them share the exact same view?