How to organize the interaction of the admin. panels and other modules?

Question

Design patterns

Hi
I'm writing a bike - I'm currently working on the admin panel. Situation:
At the moment, I have all the logic related to managing my bike (adding spare parts, replacing spare parts, deleting spare parts) in the bike controller, the views are in the same place - in the folder with the module. In the admin module, the paths were redefined so that I have access to the bike management only through the link /admin/velo. In the routing of the path of the bike module, child route admin paths are made. As a result, in the view files that are in the Velo module, I use the paths generated by the Admin module: admin/veloThis is not cool at all, the Velo module depends on the Admin module.
The thought (!) arises that you need to do this: the module will contain only those actions (action) that are needed to display the bike to the user, and in the admin panel there will be one more controller (in a different namespace) that will be responsible for managing the bike. In the admin panel, there will be views in which the paths will be used. admin/veloIn the module itself, there will be views in which the velo path will be used. Thus, there will be no dependence of the Velo module on the Admin module. But! But the Velo module will be incomplete, because there will be no module management (like, for example, the Album module from zf2-skeleton).
Bottom line:
- in the first case, an unnecessary dependence of the Velo module on the Admin module appears;
- in the second case, the Velo module will be incomplete, since it will not control the bike.
Question: what compromise to find?
I'm new to this stuff so I don't know for sure.

Answer 1

Structure of your application:
In index.php (conditional bootstrap of your application) we carry out routing.
pastebin.com/gcFPbtP8
If groups are implemented in the routing (in ZF it is child_routes), then /admin/ can be moved to a separate group:
pastebin.com/PBL6bTHt
Models are stored in the models folder. The Velo model returns data, for example, from a database.
Actions located in the VeloController delegate data to the view ( actionIndex ) or, as in the cases of actionCreate , actionUpdate and actionDelete - perform the necessary actions and produce a redirect.
pastebin.com/kMNCHV4f
Please note that the backend (admin) controller is inherited from the frontend controller:
It is possible that, for example, the addition of Velo is available not only to the site administration, but also to an ordinary mortal. With Velo not a very good example, better Comments. Likewise with models.
Just remember that using bold, ugly actions is not good practice. Filtering (sanitization) and validation of request data can be done in the model. An example with rules , if you remember.
PS I noticed that you have a lot of questions in the toster related to ZF2. Difficulties arise because ZF has a slightly higher entry threshold. For starters, any microframework could be the best choice (Laravel, CodeIgniter,...)
> Why do you have 2 models?
It is logical to assume that a request to the database to return a list of bicycles can appear both in the admin panel and for display, for example, on the main page. Deleting, adding, updating an entry can only be accessed through the admin panel. That's why:

namespace apps\frontend\models;

class Velo extends ActiveRecord
{
   public static function tableName()
   {
       return 'tbl_velo';
   }
   public function getAll($limit)
   {
      return static::find()->limit($limit)->asArray()->all();
   }
}

Admin model:

namespace apps\backend\models;

class Velo extends \apps\frontend\models\Velo
{
   public static function create($content)
   {
        $velo = new static;
        $velo->content = $content;
        return $velo->save();
   }

   public static function update($id, $content)
   {
       $conditions = ['id' => $id];
       return static::updateAll(['content' => $content], $conditions);
   }

   public static function delete($id)
   {
       return static::deleteAll(['id' => $id]);
   }
}

I wrote add/update/remove/ requests in the controller in vain.
This model is typical for Yii2, which is built on the ORM ActiveRecord (pattern) .
Doctrine uses a slightly different pattern - Data mapper .
Each model has its own controller, because the list may look different on the main and admin panel - different views. And, for example, for ajax (in addition to frontend, backend, the ajax directory will be added. For convention, let's call all this scopes) the data will be returned in JSON, i.e. without a twist.
Velo controller for frontend:
pastebin.com/diXPu5yY
Velo controller for backend:
pastebin.com/3s7EpJAD
That's all MVC ;)